Jennifer Lee and Skye Tyler in a new "How I Solved This Episode."

How I Solved This: Use a Toggle and Flow to Escape Validation Rules


Welcome to another “How I Solved This.” In this series, we do a deep dive into a specific business problem and share how one #AwesomeAdmin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Skye Tyler was able to use a toggle field and flow that allows the record to be updated, thus bypassing a validation rule, regardless of the user’s permission who is executing the flow. Read more details in the post below.


Key business problem

A validation rule prevents certain users from editing specific records. But when those users edit a related record, it kicks off a flow that edits the restricted records and the validation rule causes the flow to fail. I need to be able to continue to prevent users from editing records directly and also allow the flow to update the records, regardless of the permission of the user starting the flow.


Our client has a childcare program called Campfire. Campers can earn Camper Credits for participating in certain types of activities and cash in these credits for snacks or swag at the Camp Store. At the beginning of each camp session, a member of the Data team creates new Camper Credit records for each camper. Once the Camper Credit status is set to Active, only users with the Data Team custom permission can edit the record directly. To enforce this, we built a validation rule that only allows users with the custom permission to edit the record when the status equals Active. 

The Camper Credit record is related to a Camp Activity record that camp counselors create to track the camper’s contributions to specific activities, give them credit for those activities, and update their current standing which determines if they’re allowed to use their credits. There’s a flow that updates the Camper Standing and Credits Earned on the Camper Credit record when the related Camp Activity is created or edited. 

The flow is erroring out on the validation rule if the user who creates/edits the Camp Activity record is not a member of the Data team.

How I solved it

1. Create a Toggle field

First, on the Camper Credit record, I created a checkbox field called Toggle. There’s no need to add it to any page layouts—you’re only going to reference it in the flow and the validation rule. But make sure that all profiles have the permission to edit it.

The Toggle custom checkbox field.

2. Update the validation rule

Next, I updated the original validation rule to include the criteria “NOT(ISCHANGED(Toggle__c))”. This means that the validation rule will not fire if the Toggle field is changed.

The validation rule with the Toggle reference.

3. Create a formula variable in the flow

In the flow that updates the Camper Credit, I created a formula variable called “ChangeToggle” using an IF formula “IF(Toggle__c = TRUE, FALSE,TRUE)”. The nice thing about using an IF formula is that it doesn’t matter what the current/prior value of the Toggle field was. If it’s currently true, we’ll set it to false, and if it’s currently false, we’ll set it to true. Either way, the field value will change.

The formula flow resource with the Toggle formula.

4. Set the value of Toggle in the flow

In the Flow element that updates the Camper Credit record, set the value of the Toggle field using the ChangeToggle formula variable.

The Update Records Flow element where the Toggle value is set using the formula variable.

Business results

Now, when a counselor creates or edits a Camp Activity record, the flow changes the value of the Toggle field, which prevents the validation rule from firing and allows the Camper Credit record to be updated!

I want to point out that if you run the flow in system mode, which ignores the running user’s permission, you could skip this Toggle & Flow solution. However, if you’re following the practice of one flow per object, you might have other branches of a flow that need to respect user permissions, so running the whole flow in system mode wouldn’t work.

Do try this at home

This example was real and it’s very simple. But the principle behind it could be applied in all sorts of ways. Let your imagination run wild! Here are a couple of examples to get your creative juices flowing.


Users are allowed to enter daily time cards and only managers can edit weekly timesheets. But every time a user updates or submits their time card, the corresponding timesheet should be updated.

Opportunity Acknowledgements

When the Development team sends Thank You messages via a screen flow, it should populate several fields on the donation record. However, once a donation is marked as Posted, only the Finance team is allowed to make edits to the record.  

Let us know what you thought of this solution, and tell us how you want to use it with #AwesomeAdmins #HowISolvedThis.


Want to see more good stuff? Subscribe to our channel!