Update Createdon, CreatedBy, ModifiedBy, ModifiedOn Fields using Kingsway Soft for CRM Data Migrations

Kingsway soft is integration tool which has been done to migrate the data to a CRM environment. This a very much useful when doing migrations for CRM online instance. It is a connector which uses CRM web services when doing the migration.

It has Create, Update, Upsert, Delete (you can directly delete records from a CRM environment by making the source and the target connectors the same which makes it is as you don’t have to have an intermediate table to do this.), Merge, Convert, Execute Workflow commands.

Also you can import M:M relationship data with this.

The question remains whether you can update the createdon , createdby, modifiedby and modifiedon fields with the values from the source data.

The answer is yes, you can for 3 of the above fields, which are

• ·       Createdon(using overridecreatedon field)
• ·       Createdby
• ·       Modifiedby

The modifiedon cannot be set as of now using OOTB Kingsway tools. it doesn't give the field and use the value of the time of the update to update this field. (This might get changed in a near future update of Kingsway soft)

Also important to note if you want to have both created by and modified by values (when they are different) during the migration, you would have to do a create request (which would give you the created by field to be set) and an update request (only now you would get the modified by field).

Change the Status Reason field value when a record is created or updated

There are occasions when we want to change the status reason of a record when the record is being created or updated.

For the record created, you can set the default value of the status reason from customisation and then it would be the value, the record would be having with the creation.

But what if you don’t want that value to be set for certain records when the record is created. Ok, so you must be thinking we can do it using a custom code. Yes, you are correct.

The next question would be which stage you can set it. It could before the record is created or after the record is created. Again, correct. You would definitely go for before creation as the value would be set in the pipeline and there would be only one request and it would be for the creation. If you use post create, then it would trigger an update to the record so it would not be good. Hence before creation it is.

However when you try to change this in pre create, set a value to the status reason using custom code and send it, the platform would throw an error saying you cannot change the value of a status reason in pre create stage. This leaves us in a bit of pickle. So now we would have to do this using post create, which we wanted to avoid in the first place as it would do an update to the record.

Is there a way around this?

As you would have guessed by now, yes there is. We could use the pre validate stage for this. Have your custom code registered for the pre validate stage and have the status reason field changed in that. When the pre create stage arrives already the value is set and the stage runs without any hiccups.

For update you can use the pre update stage and it works without any issues.

Export a database created in Azure, created by CRM data export feature

With CRM 365, there is a feature that has been added to export the data to a database in Azure or a VM in Azure. This particularly very useful if

• ·       You want to use different reporting against particular data sets. Can have multiple databases on specific data sets from CRM.

o   CRM online doesn’t support SSRS reports J

• ·       If you want to display a public register (Read only access) to outside world

o   This is particularly good as you can write stored procedures to make the queries efficient rather than calling the CRM web service, which is of slow performance for such task.

To enable this you need to enable a feature called Change Tracking at the entity level where you want the entities which should be synced with an Azure database. Also needs to create an export profile to do the syncing of data.

There would 2 data pulls.

• ·       Initial data load in which the first time when the profile is created and the syncing is done. This would create the tables and will sync the data against the tables.
• 
  
• ·      Syncing deltas. This would happen only when a data is changed in the entity.

A very nice article about how to set this up can be found below.

https://blogs.msdn.microsoft.com/crm/2017/04/11/introduction-to-dynamics-365-data-export-service/

Also if you select the Azure database and you want to have a local copy of it, you wouldn’t be able to create a database backup of it. This is not allowed. Instead there is a feature called export data tier application which will export the database in to a .bacpac file.

Then to import it to the local database, there is a feature called import data-tier applications and you need to select the exported .bacpac file.

The following article was very helpful to me when I was doing an export from Azure database.

http://www.magnetismsolutions.com/blog/dinesh's-blog/2015/04/13/move-sql-azure-database-to-local-sql-server

CRM 365 Business Process Flow Changes

With regards to CRM 365 there have been some major changes to BPF. They are

•    A new entity is created per each BPF created.

o   This contain records that the BPF was ran for and the stage that they were in and the duration also. Also can set the privilege for the BPF in the security role itself.

• ·       There can be multiple BPF’s concurrently running on the same record

o   This is a nice feature as most of the clients have been asking about, but were not possible before.

• ·       Workflows can be executed from a BPF. (Stage Entry and Stage Exist)

o   A workflow could have been written to check the stage and do execute before this. But now we can execute a workflow without checking that when a stage is reached or existed from the BOF designer itself.

• ·       BPF designer changes

These are some of the changes that have been introduced with BPF’s. Following articles were really helpful to me when understanding this.

https://blogs.msdn.microsoft.com/crm/2017/03/28/business-process-flow-automation-in-dynamics-365/

https://blogs.msdn.microsoft.com/crm/2017/03/28/concurrent-business-process-flows-in-dynamics-365/

There is a small thing to know if your organization was updated from 2016 to 365. When you go to the BPF and try to set the security role to the BPF you don’t get a button to set it. The window displays the security roles. You would have to open the security role, go to the business process flow tab and then set the privilege to the role.

If your organization is brand new 365 one, you get the button to save rather than going to the security role and selecting it.

There is a way to do it for CRM 2016 as well without going to the security role. It has been nicely mentioned in the below blog. 

http://dyn365apps.com/2017/02/02/tip-business-process-flows-enable-security-roles-button-issue-after-upgrading-to-dynamics-365/

Dynamics CRM Parental Relationship behaviour

Recently in one of our projects the client came up and said that something strange is happening with created notes on a particular custom entity. What they said was there were some notes created against a custom entity record and one of the new users logged in and created a new note against that record and when another user logged in to check the record , it showed all the notes were modified by the new user, which the new user hadn’t do.

This was a strange behaviour and the client wanted to know whether we have done any custom plugins or workflows around notes. We didn’t have any and it puzzled us too.

We started trying to replicate this in our development environment to find out the reason why it was happening. We were able to replicate it sometimes and but sometimes it didn’t happen. So we drilled down to see why it was happening like that.

We were able to track it down and confirm that this only happened when we were changing the owner of the particular record. One of my colleague (Shane C) wanted to have a look at in the relationship to find out whether it is happening because of that, and he was dead right about it.

The relationship between the custom entity and the notes was a parental relationship and which meant if the owner was changed then the owner of the notes belonging to that record would be changed as well. How it works is given below.

Custom Record A is having owner AA.
Custom record A is having 5 Notes and the notes are belonging to 3 different users.

User BB comes and changes the owner of Custom record A to User DD.
According to the parental relationship as it has been setup all the Notes associated with Custom record A would be changed to Owner DD now.

Also what will happen is, all the Notes would have User BB as the modified user as well. This is because of the parental relationship changes the Owner of the notes and the user who changed the Owner of custom record would come down as the user who did the Owner change in Notes as well. This is expected behaviourJ.

It took some time to figure this out.

You can change this behaviour by changing the relationship from Parental to Cascade, but it is up to the requirement of the organization. This might not be recommended as well.