Recently I’ve been expanding my knowledge of Power Automate, and how it works. It really is a truly amazing tool, though there can be some quirks to things! There are so many connectors to use, though I haven’t really used that many of them to date.
Truthfully, most of my work in Power Automate is around CDS & Office 365. Occasionally I’ll dip into another system, but for the most part that keeps me busy enough. It’s not to say I don’t want to explore further, but finding the time can be quite difficult!
One of the great abilities that Power Automate has is to be able to update a record. With focusing on CDS entities for the moment, we would use the inbuilt action for this:
We’d run a query to get a specific record – this would give us the record ID (or GUID, depending on your preference). With this, we’d use the Update Record action & pass in the record GUID. After all, we need to know which record we’re going to update! So for example:
What we can then do is set values for the record. So we can pass in Dynamics Content, use Expressions, etc. These can be from records that are part of our Power Automate query chain, or from elsewhere.
For example, I can say that when a contact’s postcode changes (or zip code for USA), go away, look up the new city, and update it (Note: I haven’t shown the postcode lookup part below):
So this is all really brilliant. Different fields have different behaviours, of course, and we need to respect that. Otherwise the Power Automate flow won’t run, and will error. This is, of course, the digital equivalent of not trying to force a square brick into a round hole!
What we can also do is clear a field value. If for example we’re wanting to remove a value from a field, we can use the NULL expression on the field. When the Power Automate flow runs, it’ll clear whichever value the field is currently holding:
Now, one of the the field types available within CDS is the lookup field. I’m not going to go into what this is, as we should already know this!. We can, of course, set lookup fields values to populate the field, which works as expected.
However (& thanks for bearing with me so far), what happens if we want to clear a lookup field value?
Say for example that we have a task, that’s assigned out to someone. If they reject the task, we want to be able to remove them from the task record. We wouldn’t delete the task, as we still need it (& now would need to assign it to someone else). We need a way to do this.
I can hear what you’re thinking right now – mentioned above is the use of NULL, so we’d use this! Um…well, you’d think so. You can try that, but we’ve found that doesn’t always work. Additionally, that doesn’t actually seem to remove the underlying relationship that’s been put in place.
Update: Thanks to Lin Zaw Winn, who dropped me a line to let me know further information around this. The standard CDS connector (the first one that was available) allowed this to work, but the updated CDS connector (Current Environment) doesn’t allow it. Unfortunately the different connectors aren’t at parity, which is a pity!
So, there’s another way to clear lookup field values. This involves the Unrelate action that’s also available. The steps for this are as follows:
- Get the related record (lookup the record type, pass in the GUID for it)
- Use the Unrelate action to remove the connection
This will then remove the relationship, which actually results in clearing the lookup field value. In practise (for our scenario), this would look like:
Let’s take a bit of a further look at the options available here:
- The Relationship field is the relationship between the two entities (eg here it’s Contact & Task). Thankfully you don’t need to manually type this – it’s easily selected from a dropdown list.
- The URL field is the linked record itself
Note: It’s VERY important to have the Entity Name & URL values in the right order. I’d suggest looking up the connected record first (ie what the lookup field is pointing to), and using that as the Entity Name value. You’d then select the record where the lookup is saved on as the URL value.
What I’d usually suggest as best practise is to have a condition before this takes place. As mentioned earlier, removing the lookup would happen on a record update. This is because you wouldn’t be removing a field value if you’re creating the record!
But you’re not always going to want it removed. In the scenario that I’ve been dealing with, we’re only wanting to remove the volunteer if they’ve rejected the assigned task. So our Power Automate flow is set out like this:
- When Task record is updated
- Filtering on the field for ‘Task Accepted’, as we could have other things being updated on the Task record that we don’t want to trigger this particular process
- Condition to check the ‘Task Accepted’ field value
- When it’s something other than ‘Rejected’, cancel the flow
- When it’s ‘Rejected’, run the Unrelate process set out above, and stop flow
You can obviously build out other functionality within it as you so desire.
So with this in mind, how do you think you could benefit from this? Drop a comment below – I’d love to hear!
Hi, this is pretty nice but when you’re unrelating records, you can only use one-to-many or many-to-many relationship. You cannot use many-to-one relationship unfortunately. I have a requirement where I need to cascade-update children records when some of values of their parent record change. Some of the values that I monitor and need to change are lookup attributes. So if one of those lookup attributes on the parent record gets blanked out, I need to blank our related attribute on all of the child records (which of course are also lookups) and unfortunately because of the nature of these relationships, I’ve spent 2 days trying to figure this out. It works perfectly fine when there is a value to cascade-update, but when that value needs to be wiped down, I couldn’t get my Flow to work. It always fails regardless of what I try. I can probably use deprecated Dynamics 365 connector and I suppose it will work there. Very frustrating that MS doesn’t think of simple things like this.
Hi Tony
Thanks for your feedback around this. I agree that it is frustrating – it’s due to the way that Many to Many relationships work. There’s a sort of ‘back end’ intersection entity for this, which is why it works differently