Here comes another requirement and here comes Microsoft flows again to bail me out. So let’s see what the requirement was and let’s see how can we implement Microsoft flows to achieve these easily which otherwise would have required extensive coding to achieve.
So it goes like this. Basically, there are lot of custom entities in the environment and there are many parent-child relationships in between those entities and they are referential in nature. Ideally parental would have suited for some, however due to the number of parental relationship limitation in Dynamics, they would set it up as referential.
Now whenever a parent record is deleted, the associated child records would be deleted as well. Since this is referential relationship, whenever we delete a parent record, the child records are left orphaned in the system.
Microsoft flows offers you an easy way to delete records in bulk. You could easily define a flow for each child record type and use the delete record step of Microsoft flows to achieve the same.
But wait? In the above approach, we need to create a flow for each child entity type and if the number of child record types are pretty large then suggesting to build flows for each of them is not something you would want. Also if a new entity or a new relationship comes into the picture, you would need to again write a flow for the same.
So now what? After a lot of brainstorming I finally came up with a solution which is pretty generic in nature and pretty scalable as well. So let’s see the design here.
- Create a custom entity. I named it – ‘Child Record Delete Trigger’. The following are the fields I created for this entity with their purpose.
- EntitySet Name – This would hold the entity set schema name for the child record type to be deleted
- Child Record Id Name – This field would hold the schema name for the Unique Identifier of the child record
- Parent Field name – The field would hold the schema name of the parent record field associated with the child record. Basically this would be the lookup field name of the parent record on the child record.
- For testing this, I create a new entity named ‘Flow Test’ which has a N:1 relationship with Contact entity. Screenshot for reference.
- The lookup field of the contact has the schema name – new_contactid as seen from the above screenshot.
- The basic idea is to create a ‘Child Record Delete Trigger’ record whenever a parent record is deleted.
- I created two records of Flow Test with Contact = ‘Catalina Weeks’
- I go ahead and delete the contact ‘Catalina Weeks’. On delete of the contact record, I create a record of ‘Child Record Delete Trigger’ entity with the following values
- EntitySet Name – new_flowtests (since this is entity set name)
- Child Record ID Name – new_flowtestid (this is schema name of the primary key of the child record to be deleted)
- Parent Field Name – new_contactid (lookup of the contact field on the child record)
I leave it up to you to determine on how to create this record, whether through a plugin or through a workflow or some other methods. As long as you create the record properly with all the fields populated, it is going to work.
So all set and done. The next step is to create the generic flow to delete the child records.
The first step is to select the Dynamics 365 Step – When a record is created.
Below are the configurations for this step.
Now when a parent record is deleted, all the child records parent reference would be null. So the next step is to determine all the child record for which the parent reference is empty.
For this, I select the Dynamics 365 – List Records step.
Below is the configuration for this step.
As you can see, I have selected dynamic properties for all the steps in List Records. I am getting all the child records where Parent reference is null. As you can see, no entity names and field names are hardcoded. It takes from the ‘Child Record Delete Trigger’ record we created when the Parent record has been deleted.
So far so good. So now what? Now we need to iterate through each of these records and delete them
So we add the ‘Apply Each’ Step.
Now comes the hard part. To delete the record you would need to use the Dynamics 365 – Delete a record step which requires a unique identifier. However the problem here is that the flow designer at the design time does not know which entity record you are trying to delete. So it does not show up the UniqueIdentifier field in the designer.
So we have to basically make the runtime understand the Unique Identifier value (GUID of the record) so that the delete step is able to delete the record. For this we would use the Compose action.
So what we have done here? Remember when we created the Child Record Delete Trigger record, we populate the field ‘Child Record Id Name’ with the schema name of the primary key of the child record.
So we use the compose function to parse that Unique ID field schema name.
Great! Now the second task it get the schema name and pass it to the framework to get the GUID. For this we use another “Compose’ action but this time, we plugin some custom expression of our own.
So what are we doing above? We are taking each item of the iteration which is identified by item() and then getting the value of the Guid of the record by passing the name of the primary field which we composed from the earlier step. This is similar to accessing a value using an indexer.
The final step is the Delete Record Step of Dynamics 365 which is very simple as shown in the below screenshot. All we are doing is getting the guid value of the child record from the previous Compose action step and passing it to the delete step.
And we are done!
So I deleted the contact. As expected, the child records were left without the parent contact reference.
A record of Child Record Delete Trigger entity got created with the following information.
So the Flow should fire now.
I check that and confirm that my flow ran successfully. And when I visit my child records list, I could see that all my child records have been deleted.
Simple and powerful isn’t it.? The same generic flow can be used for any entity/ relationship and in the whole flow you have deleted the child entity records without even know which entity it is.
Hope you liked this.
(Visit our products page at www.xrmforyou.com to know about our offerings)