{Dynamics 365 + Microsoft Flows} Generic framework to delete all child records when a parent record is deleted in Dynamics 365 using Microsoft Flows

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 Namenew_flowtests (since this is entity set name)
    • Child Record ID Namenew_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)

{Dynamics CRM + Sharepoint Metadata Integration}–SharePoint Metadata Manager & Attachment Extractor. What’s new?

First of all, I can thank more to the Linked In community for the overwhelming response on our SharePoint Attachment Extractor and metadata manager tool. Your feedbacks, your comments and your patronage keeps us motivated to continuously excel and do better.

In case, you are not aware of the tool, this quick video on the link would help you get started.


You can follow this blog link as well which explains in detail the functionalities of the tool


Based on the feedbacks of many who have tried our tool and our customers, we have implemented multiple changes to the tool related to performance enhancements and adding new functionalities to aid you.

For trial and pricing, please reach out info@xrmforyou.com

1. Performance Enhancements

We are happy to let you all know that we have made some significant changes in the underlying framework to increase the performance. Many were facing performance issues while trying out our tool in the online trial environments specially in the EMEA and APAC regions as the online trials were performing reasonably slow in these environments.

We cannot do much for the online trials :). Hence we decided to work on the performance of our tool. You would find visible performance difference in the retrieve, upload, delete and even in the metadata management sections.

We would be sending out the new trials to all who queried for it and the updated licensed version to all our existing customers.


2. Support for SharePoint Document Locations

Our prior version just relied on the Document Management to be enabled between CRM & SharePoint. Once it was enabled, it would work independently. Meaning OOB CRM – SharePoint integration creates a SharePoint Document Location object for each record for which a document is uploaded.

However our previous version did not rely on this and it would communicate directly to SharePoint. Hence documents uploaded using our tool was not visible in the OOB upload section. This was a requirement for many. Hence we have included support for SharePoint document locations. This means documents uploaded from our tool and OOB Documents area would be visible through each of the areas.

Documents Uploaded through our tool



From OOB CRM Documents area



3. Drag & Drop

What’s a modern app without the feature to drag & drop. And that’s why we have enabled the drag and drop feature on our tool as well. All you need to do is drag an drop the files from your desktop to our control on the form and they will be uploaded for you.

P.S – Drag & Drop feature is currently only in the licensed version. However we are planning to bring that to trial very soon


4. On-Premise support.

Why leave out the old horse? In the days when Online is talked so much, we do care about our on-premise customers. Our tool now supports On-premise environments as well.


And finally a big announcement to make. We are going to come with just the attachment extractor to move your attachments from any entity in CRM to SharePoint. This tool maintains all its functionalities but we are separating out just the attachment extraction part of it and bundle it into a separate tool with lot of configurable options for you.

Stay tuned.

For trial and pricing, please reach out to info@xrmforyou.com.

Visit our products page http://www.xrmforyou.com/products-1.html

-Debajit Dutta

{D365 + Sharepoint + Microsoft flows} Delete attachments from corresponding SharePoint folder when a record is deleted in CRM using Microsoft Flows

Off late, I have been working with Microsoft flow and boy! I am liking it. It is cool and specially considering the fact that it simplifies whole lot of stuffs that you would normally require to write lot of code, make it even more appealing.

So here I was with a requirement.

There was OOB CRM-SharePoint integration enabled and the client wanted that whenever an entity record is deleted from CRM, the  documents in the corresponding SharePoint folder should be deleted as well.

Now the OOB behavior does not support that. Even if you delete the record, the folder corresponding to that is present in the SharePoint path with all the documents.

So what are my options here. Well some custom code that would run when the record is deleted in CRM and that code would be responsible for deleting the documents from the SP Folder. On top of that, if you are in online, you cannot use the client object model of SharePoint from your CRM plugins. You would require to make use of REST API of SharePoint which is way more complex that the client object model.

But wait, don’t worry. We have Microsoft flows. So let’s explore how can we achieve this using a few tricks and the very wonderful Microsoft flows. And let’s explore how this generic framework will work for all.

For my example, I will select the Contact entity.

Here is my contact record for which currently 3 documents are uploaded.


Below is the Sharepoint folder location for the same.


As you already know, when you enable OOB CRM-SP integration, the folder for each record for the first time gets created in the format of <Primary Attribute Name>_<Record Guid with ‘-‘>

In my case the folder name is – Darren Parker_69a0e5b988dfe311b8e56c3be5a8b200

I create a custom entity in CRM called – ‘SP Folder Delete Trigger’. And create a custom field called ‘Document Location’.

Whenever I would delete a contact record, I would create a new record of ‘SP Folder Delete Trigger’ and the Document Location field would contain the corresponding path of the Sharepoint folder. So if I delete the contact “Darren Parker”, I would create a record ‘SP folder Delete Trigger’ with Document Location as /contact/Darren Parker_69a0e5b988dfe311b8e56c3be5a8b200

How to create this record? Well I leave this up to you. Plugins, workflows, action? In what so ever you want.

Ok. But don’t create the record now. Let us first design a Microsoft flow which would do wonders. But how do I use it? Well, just like any other Microsoft feature, it is as easy as it gets. I will start from the beginning of how to enable flows for your organization. Readers who are already aware of the same can just skip the first few set-up steps.


  • If you are using first time, it will set this up for you. In either case you would land up in a screen like the one below.


  • Click on ‘Create from Blank’ button
  • In the search area, type ‘Dynamics 365’. It would show all the operations available for Dynamics 365.


  • Select the step – “Dynamics 365 – When a record is created”.
  • Enter your organization name and entity name. It will be present in the list of available options.


  • Click of ‘New Step’ –> Add an action


  • Select sharepoint and then select the Sharepoint – List folder action


  • Select your Site Url. It would be auto populated.


  • Now comes the important part, the folder identifier. Basically, it is the path to your folder. Since we are making a generic framework here, we won’t hardcode the folder path. Rather we would be passing the dynamic property. So what is the dynamic property

You remember we create a field called Document location which contains the path to the folder. So we set this field to the Document Location property of the created record.



  • Since we are using a dynamic property here, our flow works for any entity and any record. It’s not specific to entity type or record guid.
  • Now we have our folder. But we need to iterate through all the files in the folder and delete them right? So we need a for-each statement here. Let’s see how we can accomplish this.
  • Select Add step –> More –> Add an apply to each.


  • The for-each construct is being applied. In the output select ‘body’ from the previous List folder step


Remember, this body is nothing but the each of the files contained in the folder.

So the next step is to delete the files.

  • Select Add Step-> Add an action-> Sharepoint –> Delete File


  • As usual select the sharepoint url from the available options. For the file identifier, select the Id from the output of the previous step.


All set and done. Save the flow. Your flow is up and running.

Remember, we have not created the ‘SP folder delete trigger’ record. Since our flow is active now, we will do the same now. Here is the screenshot below of the same.


wondering the document location we mentioned for our example was different – /contact/Darren Parker_69a0e5b988dfe311b8e56c3be5a8b200. But the screenshot above shows a different. Well, it’s the same value. The value is just URI encoded. But why is it necessary?

This is because, the flow will internally use the REST API to query SharePoint and when our dynamic property ‘Document Location’ would be evaluated in the workflow, ‘/’ will not be a valid character and hence the flow would fail. Remember, this is very important to remember that you need to put the URL encoded values here to get the flow running. A simple mistake like this would take days to resolve and you would wonder what wrong you are doing.

So I created the record. My flow would fire now.

Go to My Flows and click on the information icon next to your flow.


Check for ‘Successes and Failures’


In my case, the flow has run and has executed successfully.

And if I go to my contact folder now, it is empty.



Awesome isn’t it? No code and you have set up something which talks between CRM and sharepoint.

And this flow works for all entity and all records. Just you need to set the Document Location property accordingly which can be done easily in CRM.


Hope you liked this. I will come up with some more interesting examples for flows. Till then, happy CRM’ing


-Debajit Dutta

(Visit our products page at www.xrmforyou.com to know about our offerings)

{Dynamics CRM/ 365 + Quick View Forms} Refresh Quick View form control programmatically using new Client side API for Quick View forms in Dynamics 365

Recently I came across a requirement where the customer needed to refresh the quick view form on an entity on change of the related field programmatically. So let me explain the requirement here.

  • Let’s say we have custom entity – “Quick View Test”.
  • Quick View Test has a  N:1 relationship with contact.
  • Quick view form of the contact is designed as shown in the screen shot below. It has the following stuffs
    • First Name
    • Last Name
    • Email
    • A sub-grid showing Related emails


  • The form for the Quick View Test Entity is designed as follow


So far so good. The requirement here is when the user changes the contact lookup on the entity form, the quick view form should refresh and reflect not only the new contact’s first name and last name, but should refresh the associated emails grid as well to show the emails associated to the contact.

Wondering what’s there to worry about? Doesn’t changing the contact lookup automatically trigger refresh of all the controls on the forms?

Well, unfortunately it does not.

I have a contact called Andrew Book with two associated emails.


However when I change the contact lookup on the form, the grid in the quick view form does not refresh.


The user have to explicitly refresh the grid to view the associated emails.

Well this can be done with a simple script with the help of new Client API’s for Quick View Forms.

// JavaScript source code

function QuickViewFormTest() {
    var quickViewControl = Xrm.Page.ui.quickForms.get("related_contact");

    if (quickViewControl != null) {
        setTimeout(function () {
        }, 500);

Register this function on change of contact and you would see the grid refreshing.

You might be thinking, why there is a timeout of 500 milliseconds. The reason is when you change the contact lookup OOB it fires a refresh of the quick view form which unfortunately does not refresh. Our custom code fires another re-fresh just after that which loads the grid.

If you want to access the individual controls on the Quick View form, you would even do that using the below code.

var emailsGrid = quickViewControl.getControl(“grid_emails”) // grid_emails is the control name


The above code access the grid in the quick view control and refreshes the same.

Hope this helps!


-Debajit Dutta

(Visit our products page at www.xrmforyou.com)