You implement Microsoft Dynamics CRM and create a custom entity called “Account Review” as a child of the account entity. This entity is part of a sales management account review process. You make the entity relationship parental so that deletions and re-assignments of account records will cascade to related Account Review records.

Five years later, when you upgrade to a new version of CRM, you notice that the Account Review records are not really being used–some use it, but it was a good idea that never really was adopted by sales managers. You don’t want to delete all of the data in the entity, but to simplify, you remove security role access to the entity and remove it from the sitemap so users won’t see it.

After the upgrade you notice that your ERP integration that updates accounts is failing. The reason is that the user that the integration process is assigning the account to doesn’t have permission to read the related Account Review entity. But the integration process doesn’t reference that entity. What’s happening?

The reason for the error is because the Account entity has a parental relationship with Account Review. When updating records that have associated Account Review records, when a record is reassigned, the assignment cascades to the related Account Review records. If the user to whom the Account is being reassigned does not have permission to read the custom entity (since we removed it from their security role), the update step will fail.

Lesson learned: When updating an existing customization and removing entity permissions from a security role, always verify if there are any parental or configuring cascading relationships with that entity, and if the users with that role will ever have a parent record assigned to them. if that is the case, change the relationship to configurable cascading and turn off cascading for assign.