{Know -How} MSCRM Recommendations during the data migration

Reparent Settings, CRM JOB Editor Tool and POSTS configurations checks during data migration.

Reparent settings-Check 

Problem Statement:

There is a huge increment of POA table [Principal Object Access].We went ahead and analyzed and understood that one of the reason was, reparent settings enabled for the entities which was creating the POA records which is not useful.

 Analysis:

  We need to know what kind of records that was creating in the POA table due to this relationship behavior and before that we need to understood that how the POA records are

Creating when we shared the records with the users and team. Just shared the records with the users and team and understood that POA records are creating with the Access mask with the given privileges as shown below.

Then we have started to query the latest production database and checked the count with the condition of inheritedAccessRightsMask=135069719 and AccessRightsMask=0

These records entry in the POA table is due to reparent attribute set to Cascade All of the major entities like activities, opportunities, etc., Reparent attribute set to Cascade All due the following relationship between master and child entities as shown below.

For Instance, the entity Y has the same setting with the Reparent Attribute set to ALL as part of the Parental relationship with the X.

Whenever the Y entity record is created in the system and found the entry in the POA table.

Have changed the behavior from parental to the cascading behavior and set reparent to cascade none and, again created the Y, no entry in the POA table. If we see the value 135069719, it is just the bits in the table above added together, except 32 (Create), i.e., 1+2+4+16+65,536+262,144+524,288+134,217,728.

 Basically these records are more and growing for each and every assignment transactions for this kind of relationship behavior set up. We need to control the growth of these entries in the future environment. These records are not deleted by the deletion service because When the inheritedaccessrightsmask value is marked as Zero those records are deleting by the deletion service, because this zero value means no privileges.

With this inheritedAccessRightsMask=135069719 and AccessRightsMask=0 deletion service will not delete and it remains there in the table and we need to find an option clear out from the table.

Lesson learnt:

Instead ,before  going for any data migration we need to check with the business and take a decision whether this default behavior is required or not and if required we can enable it  once after the migration is done and it will help the new environment to keep clean without these unnecessary records.

CRM Job Editor Tools and POST configuration - Check

Let’s begin:

      As everyone aware that CRM Job Editor Tool and its uses and here we will see some other details of its uses.

During the data migration we can enable this and schedule it so that even during the data migration also it will run and will do its job.

For example, it will reindex the indexes if it fragmented and it will delete the unnecessary entry in the POA table, etc.

This is required when we are migration the huge number of activities record and there is a chance of indexes are getting fragmented due to huge continuous data migration and if this jobs run scheduled time it will reindex it properly so that data migration also will be faster mainly for activities.

These system jobs can be seen in the CRM application as well as shown below.

From the CRM application itself we can see the last when it ran and next when it will run.

 POST configuration settings:

    As we everyone aware some customers like to have POSTS in the social pane and some customer does not like to have the POSTS in the social pane if they are not using.

Generally we will forget these kind of configurations check once after the data migration and we will publish the new migrated environments to the end users as it is. After seeing the POSTS in their main entity in  social pane it was a confusing scenario for them.

End users will raise a defect to resolve. Instead if we could does before it will stop the unnecessary confusion among the end users as shown below.

Just Look for the POSTS configurations from the Advanced Find and select the entity which you want to

Disable the POSTS configuration and disable it by  unchecking the check box[Enable or disables the wall on the entity form] value as shown below.

By doing this POSTS will not shown in the social pane.