Sudipta Deb

Sudipta Deb

Founder of Technical Potpourri, Co-Founder of Shrey Tech, Enterprise Cloud Architect

In the dynamic world of Salesforce, the ability to create, modify, and manage data processes is fundamental to ensuring that business operations run smoothly and efficiently. Salesforce Flow, a powerful tool in the Salesforce arsenal, allows users to automate complex business processes with a visual drag-and-drop interface. However, as with all software tools, things don’t always go as planned. Sometimes, processes can result in unexpected changes or even errors. That’s where the need for a rollback functionality comes into play.

The inclusion of rollback in Salesforce Flow is not just a luxury—it’s a necessity for maintaining data integrity, reducing risk, and providing a safety net for administrators and developers alike.

In this blog post, I will explain how to introduce Rollback functionality within Salesforce Flow.

Read this blog post or watch the video below to understand how to perform Rollback in Salesforce Flow.

Prerequisite – Case Validation Rule

I have created a validation rule in the Case object which is – Case creation will fail if the case priority is set, but the case description is blank. Here is the Case Validation Rule.

Prerequisite – Screen Flow

I have created the below flow with the functionality as mentioned –

    • Step 1 – Screen Element – Capture Contact First Name, Last Name, Case Origin, Case Description & Case Priority
    • Step 2 – Search Contact – Search for any existing contact with the same First Name and Last Name.
    • Step 3 – Decision – Check if the existing contact found or not
      • Step 3.1 – Contact Found – Set the Case Contact Id with the existing Contact Id.
      • Step 3.2 – Contact Not Found – Create the contact and set the Case Contact Id with the newly created Contact Id.
    • Step 4 – Create Case – Finally create the Case record.

Problem With The Above Flow

In the above flow, if the Case Description is not given on the first screen, and then if the existing contact is not found, then Flow will create the new contact. But when Flow will try to create the case, the flow will fail, because the validation rule will not allow Case creation when the description is blank, but the case priority is set.

But the actual problem is somewhere else. By the time Flow fails, contact is already created in the system. But since they (contact and case creation) are part of the same transaction, if one fails, the entire transaction should be rolled back to keep the system in a consistent state.

This is where we need the new “Rollback Elements” from Salesforce Flow.

Introduce “RollBack Element” From Salesforce Flow

Here I am going to update the above flow to handle the rollback scenarios.

    • Step 1 – Add the Fault Path – Click on Create Case Record Flow element and add the Fault Path
    • Step 2 – Add Roll Back Records Element – In the Fault Path, add the Roll Back Records Element and give it a name.
    • Step 3 – Display Error Message – Add a screen element to display a custom error message.
    • Step 4 – Connect Elements – Connect the Display Error Message element with the first screen from where Case/Contact inputs are coming.

This is how the flow is looking after the changes.


After making changes as mentioned above, if I do not provide Case Description in the first scree, flow will show my custom error message and take me to the same screen to update the case description. But the important part is due to “Roll Back Elements”, contact created will be rolled back.

Final Thought

In the vast realm of Salesforce, the ability to execute and modify automated processes is crucial. While Salesforce Flow is instrumental in enhancing operational efficiency, the absence of rollback functionality could be its Achilles heel. It’s more than just an added feature—it’s a safeguard that ensures data remains intact, minimizes potential disruptions, and instills confidence in users. In a world where data is gold, the rollback capability in Salesforce Flow is the shield that protects this invaluable asset. Ensuring accuracy and trust in our systems is not just desirable; it’s imperative.


This article is not endorsed by Salesforce, Google, or any other company in any way. I shared my knowledge on this topic in this blog post. Please always refer to Official Documentation for the latest information.


Submit a Comment

Your email address will not be published. Required fields are marked *