#Flow — Edit Owner of a child record when parent is reassigned. Bonus: handling the Regarding field
This might be a useful and repeatable pattern for Customer Service/Case Working scenarios.
All types of Activity records in Dynamics are related 1:1 with a special Activity (activitypointer) entity which is not very configurable. For example, we cannot add custom fields to Activity in the same way that we can add custom fields to Email Message.
As a consequence, the views of Activity carry the main fields of the Email (and task, phonecall, meeting, etc) but no custom fields. If we implement a GDPR warning flag in our customer service app to note that a certain email message is known to contain sensitive data, the user will only see that custom field in the Email record, not when browsing the Related Activity view from the Account or Case forms.
One possible approach is to create an Activity Summary custom table which works in parallel with all activity types. In my environment there were 8 of them, considering both the custom activities and those that Microsoft implemented as part of the Outlook/Exchange integration.
We’ll need one Flow/workflow per activity type to create the Activity Summary when an activity record is created. We can copy the Title and other fields from the activity to the Activity Summary and from that moment on, we’ll see a lot of new records being created, one per activity.
After that, we will want to keep some of that data up to date when the originating activity is changed by users or processes. For example, the Title of a Task could change. I would not want to replicate every single field of the task in the Activity Summary, just… a summary: status, title, owner, regarding and my custom fields that I need to show in the Related tab of my Account or Case.
Now what’s interesting is when the Owner or the Regarding field of the activity could change. Both are lookup fields and at any time they can “point” at one of several possible tables. A simple update a record action in Flow will not do the job:
When we update the Owner from Jane Doe (User) to Customer Service (Team), the update above will break. That GUID will not exist in the specified table. To make this work, we need to prepare for both scenarios. After the Flow trigger, I made a Compose action:
This takes value from the Trigger Output
triggerOutputs()?[‘body/_ownerid_type’]
to return a string containing “teams” or “users”. This was the convention at the time of writing (November 2021). Therefore, I need to add a condition ahead of the two possible updates to my Owner field:
Now the two possible update row actions can safely point at the right table when updating the Owner lookup:
Bonus!
While Owner can have two types, Regarding can have… a whole bunch of them, including a null()
This one took me a lot of trial and error, so I’ll show the formula without promising to understand exactly how this worked out:
Until I had both Compose actions, the second one was not giving me the actual type, only the GUID, even though the field was pointing at something that was not the _regardingobjectid_value. Notice also that I needed a Get Row by ID action to make this work.
Could have been a temporary glitch, now recorded for posterity.
One final quirk: Switch does not accept a null when evaluating each case, therefore I applied this formula to cover those situations when the Regardingid is blank:
In my scenario the Type could have been account, incident, a custom entity, or null. Notice that here the entity names are in the singular. I don’t know why this would make sense, but using the Compose actions helped me see the different outputs as I ran the incomplete Flow several times until it worked end-to-end.
