Debug Flows as Another User

Learning Objectives

After completing this unit, you’ll be able to:

Debug a flow as another user.
Change a flow’s context.
Enable rollback on your debug runs to avoid affecting your data.

The previous badge, Flow Implementation I, is required (so that you can reuse its playground). You need the package installed and we don't cover that installation in this badge.

Because it's impossible to anticipate everything that might cause a flow to fail, the best way to be sure users can run your flow is to run the flow as your users. Fortunately, Flow Builder has a feature that lets you test a flow as a specific user, just as if they were running the flow themselves.

Enable Debugging as Another User

Before you can simulate another user running your flows, you must enable a specific setting.

From Setup, enter process in the Quick Find box, then select Process Automation Settings.
Enable Let admins debug flows as other users.
Click Save.

Debug a Flow as Another User

Let’s debug a flow. The Close Case and Tasks flow gives support users the ability to close a case and all of its tasks with a single click. It runs from a custom button on the Case object.

In your Trailhead playground, find the “Motor breaks down when turning on” case and copy its ID from the URL bar.
You need the case ID to debug this flow. It’s the 18-character string found in the case’s URL between Case/ and /view. It’ll look something like 5008b00002OPpwGAAT but it’ll be different in your org.
Open the Close Case and Tasks flow.
Click Debug.
Select Run flow as another user.
In the User field, enter Ezra, then select Ezra Mustang.
In the Input Variables section, enter the case ID from step 1 in the CaseID field.
Click Run.

Salesforce runs the flow as if Ezra Mustang clicked the button to run the flow, and shows the results in the Debug Details sidebar. It failed!

The debugged flow and its Debug Details, with an error message corresponding to the following description.

When you debug a record-triggered flow, you can click Convert to Test to convert your debug values to a flow test. The Triggering Record becomes the Initial Triggering Record, and the Update the Triggering Record fields become the Updated Triggering Record. Use this feature to knock out both the test creation and debug steps at the same time!

Troubleshoot the Debug Error

Notice that there’s an error in the debug details. The Close Tasks element failed with the error message: The flow tried to update these records: null. This error occurred: INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY: insufficient access rights on object id.

The “null” means it couldn’t find any tasks, but we know there’s a task on that case. “INSUFFICIENT_ACCESS” provides a clue that it might be an access or permissions issue.

Doing some detective work in the org, Flo finds the following access and permission settings.

This flow is an autolaunched flow, which means its default context is System Context With Sharing. This context means the flow can access only the records that the running user can access.
In Sharing Settings, the organization-wide default for Activities (the object that includes tasks) is set to Private. This setting means that only a task’s owner can see or make changes to that task.
Ezra Mustang has the Pyroclastic Support permission set, which doesn’t have any overarching data access permissions, such as Modify All Data, that would override the organization-wide default.
There is one task on the case we used to debug the flow, and it’s assigned to you, not to Ezra.

So it makes sense that the flow failed when editing the task as Ezra Mustang. That user can’t edit tasks that aren’t assigned to them. In the Pyroclastic org, it’s quite possible that a case’s tasks could be assigned to anyone. So Flo needs to either: A) loosen Task security for the entire org, or B) change the flow so it can close tasks assigned to any user. Solution A poses a greater security risk for the org, so let’s use solution B instead.

Change the Flow’s Context

Click Edit Flow to return to the editable Flow Builder canvas.
Click .
Click Show Advanced.
For How to Run the Flow, select System Context Without Sharing—Access All Data.
This setting determines the context that the flow runs in. Remember, system context without sharing means the flow runs with access to all objects and fields, and ignores record sharing. In other words, this flow can now edit any task, regardless of who owns it.
Click Done.
Save the flow.

Now use Debug to run the flow as Ezra Mustang once more, with the same case ID in the CaseID field. The flow should complete successfully! (You’ll know it completes successfully if there are no errors in the debug details.)

The debugged flow and its Debug Details with no error messages.

One final thing: Go look at the “Motor breaks down when turning on” case record once more.

The Follow-up on status task, with Status set to Deferred.

Notice that the task is now set to Deferred. Yes, your flow updated the task record when the debug ran successfully! This behavior is one key reason why you should always build and test flows in a sandbox. You can also prevent your debug runs from affecting your data by selecting Run flow in rollback mode in the Debug flow window.

The Debug flow window, highlighting the Run flow in rollback mode setting corresponding to the previous description.

As a best practice, follow the Principle of Least Privilege and change the context only if the flow’s intended users need a more permissive context to complete the flow.