Debugging Tips for Salesforce Orchestrator

These guidelines apply as of Spring ’22. In general, the idiosyncracies and gaps that are discussed here represent things that the development team just hasn’t had a chance to get to yet.

Key Debugging Concepts

Use the Orchestration Run list view to access the debugger for in-process orchestrations.

Unlike screen and autolaunched flows, there’s no Debug button in Flow Builder for orchestrations. There probably will be one at some point, but the best explanation is that the mindset of an orchestration is oriented around it being ‘In Process’, and there’s going to be a different place where you manage your In Process orchestrations than the Flow Builder canvas.

The first thing to get comfortable with is the Orchestration Run list view, which you can access from the waffle

This produces this view:

The Debug and Cancel menu items are only available on In Progress runs.

You can debug a paused orchestration, and you can debug a failed (errored) orchestration, but you can’t debug a completed orchestration

Suppose you are trying to figure out whether a value is being output by a step flow as expected. You could run the step flow in isolation, but then you have to simulate the inputs that it gets, and that can take time and be unreliable.

As long as you have at least one Interactive Step, the orchestration will pause and you can click Debug Orchestration, as shown above. If you don’t have anything to stop the run from hurrying through to completion, you won’t have a way (for the time being) to inspect intermediate values.

If you do have an all-Background Step orchestration, you can tack on a placeholder Interactive step to ensure you can fully inspect the values. Here’s an example:

You can also insert a step that causes an error, because the error email will contain the same information as the debugger:

Note that when the error happens in a step flow, you’ll get two error emails, one for the step flow and one for the orchestration (which is also a flow).

If you want to inspect intermediate step flow values, use manual variables

Orchestrator currently shows, for each step flow, the inputs that went into it and the outputs that came out of it:

However, Orchestrator does not yet show each element of the Background Step. In the case above, I was debugging a problem with the Flow Interview and wanted to see what value was output from the Get Records call here:

Usually, I use automatic outputs and don’t create manual variables, but because of the limitation of seeing the internal elements of background steps, I elected to create a variable to store the Flow Interview and clicked ‘Available for output’:

Then, in the Get Records, I manually mapped the field I cared about to this manual variable:

As a result of this, I’m able to observe what was being returned for Flow Interview, even though it’s in the middle of the Background Step:

If you choose to do this, be careful about other things downstream in your flow that might mutate the value of your variable before it gets output.