Update Child Records in Dynamics 365 using Microsoft Flow
It has been a vexing challenge to keep Contact records updated with information that changes on their parent Account Record. The only solution to date has been to write a plugin to update Child records when the Parent record is updated. This required someone who knew the SDK and could write C# code. Once it got coded it was expensive to maintain as any change in the logic required getting the developer involved again. It wasn’t Functional Consultant friendly.
Microsoft Flow comes to the rescue! Using the Common Data Service triggers and actions with a little bit of geeky expression writing thrown in, it now can be done and updated easily.
The example below is for the typical Account – Contact relationship. But it could be morphed into any entity type that use parent/child relationships.
I will outline the 3.5 step process.
Step 1 – Create the Trigger event – in this case I have set the trigger to fire when an Account record is updated without specifying any specific field. I am also configuring it to run only on records I own.
Step 2 – This is where I tell Flow to find all the Contact records whose Parent record is the one from the previous step. The key element here is the ODATA filter query (thank you David Yack for your hint) – be sure to include the underscores. The dynamic value is the Account GUID from the record in Step 1.
Step 3 – Now select the Update Record Action. Once you do this and fill in the fields, Flow takes care of the Apply to each loop. So don’t get confused by this and look for a Apply to each. You don’t need to do this. Just add the Update Record action.
Step 3.5 – This is where you specify which fields in the Parent Account (the source) are pushed to the Child Record(s) (the target). In this example I am getting the Main Phone number field from the Account and updating all the Contacts records Business Phone Field.
My thanks to Joel Lindstrom for posing this question to me that got me thinking about the solution.
Is there any reason not to use the Dynamics 365 connectors instead of the Common Data Service connector you used in the example?
Adam, see this blog post I just made in answer to your question.
How do you manage the flows between different environments e.g. Dev, Test, Production?
This is evolving and maturing. Check out this post to get you started. https://flow.microsoft.com/en-us/blog/solutions-in-microsoft-flow/
Can this method be used for the following use case:
Execute a workflow on an account, find the most recent proposal, pull data from that proposal to use in an email automatically sent from the flow?
The proposal would be custom entity?
We have renamed the Opportunity entity to Proposal. In this case its just the standard opportunity.
Essentially, however, its to pull data from a particular related record having the 1:N relationship with the current record.
Gotcha. Good idea for another blog post. How would the Flow know which Account to trigger off of? And in your system there could be several Proposals (opportunities) per Account. We would also have to get the most recent Open proposal. Could the Flow be triggered off of a change to an attribute? Let me know and I will work something up.
[…] Jerry Weinstock: Update child records with Flow […]
Which of the many confusing flow licenses is required?
Does each update count as a flow execution?
Any answer I would give regarding licensing would be prefaced by, I believe. So the answer to your question is I believe it would require a PowerApps P2 license since the Common Data Service is a Premium Connector.
Each update would count as a Flow execution. Stay tuned for a blog posting later this week while I show how you can control when the Flow is triggered which would reduce the number of Flow runs. Also, remember that Flow run allowances are aggregated at the tenant level so you get the sum of your allowance for the entire tenant for everyone to run against.
Can we do vice-versa? How can we update the Parent record when a child is updated?
You certainly do this with Flow. But recognize looking up from a child record to it’s parent and updating the Parent has always been a doable process in traditional CRM workflow.