Rajeev Pentyala – Microsoft Power Platform

Imagine a scenario where you need to perform the following actions as a transaction: if any operation fails, all completed operations should be rolled back.

• Create an Account record.
• Create a Contact record by setting the Contact.CompanyName as Account created in previous step.

To achieve this scenario in Power Automate, we can utilize the Perform a changeset request action. However, it’s not straightforward, and I’ll explain why.

Lets first understand Perform a changeset request action before proceeding with our scenario.

Perform a changeset request:

• Change sets provide a way to bundle several operations that either succeed or fail as a group.
• When multiple operations are contained in a changeset, all the operations are considered atomic, which means that if any one of the operations fails, any completed operations are rolled back.

Now lets configure the flow with Perform a changeset request action to achieve our scenario.

Configure flow using Perform a changeset request action:

• Create a new Instant flow
• Add a Initialize variable action and set Value as guid() expression.
  • If you are wondering why we need a new GUID, you’ll find out by the end of this post.

• Add Perform a changeset request action and add two Add a new row actions to create Account and Contact records.
• First Add a new row action, select ‘Table name’ as ‘Accounts’. Important thing here is to set the Account primary column as :

variables('vAccountId')

• In the second Add a new row action, set ‘Table name’ as ‘Contacts’ and set ‘Company Name (Accounts)’ column as :

accounts(variables('vAccountId'))

• Once configured, flow looks as below.

• Save and test the flow.
• After the flow run, you’ll see a new Account created along with the child Contact record.

• Now, to test the rollback behavior of the Perform a changeset request action, let’s intentionally fail the Contact creation action and observe if it also rolls back the completed Account creation.
• To intentionally fail the Contact creation, I’m setting a non-existing GUID in the ‘Company Name (Contacts)’ field.

• Save and Test the flow.
• After the flow run, you’ll notice that it failed with the message ‘Entity ‘Contact’ With Id = xxxx-xxx-xxx-xxxx Does Not Exist’. This occurred because we intentionally passed a non-existing GUID. Additionally, the ‘Create Account’ action was skipped, which demonstrates that the Perform a changeset request action ensures that if any operation fails, any completed operations will be rolled back.

Now that we understand how the Perform a changeset request action behaves, let’s also explore why I had to use pre-generated GUID in our flow.

Reason for using a pre-generated GUID in our flow:

Perform a changeset request action has following limitation:

• We can’t reference an output of a previous action in the changeset scope.
• In the changeset scope, you see that there are no arrows between each of the actions, indicating that there aren’t dependencies between these actions (they all run at once).

In our scenario for creating Accounts and Contacts, if we don’t use pre-generated GUIDs, we can’t get the platform-generated ‘Account GUID’ from the ‘Create Account’ step to pass it to the ‘Create Contact’ step.

So, I had to use the prepopulated GUID in both the ‘Create Account’ and ‘Create Contact’ steps to work around the limitation with the Perform a changeset request action.

That’s all for this post. I hope you now understand how to use the Perform a changeset request action.

🙂