Salesforce Flow: What is going on in there!?

Salesforce’s Visual Workflow and Process Builder are incredibly powerful tools but can be very difficult to troubleshoot. I struggled to make these tools effective until I was able to get a glimpse of what was happening inside. Salesforce has some suggestions for how to troubleshoot failing flows but often these tools provide incomplete answers. Particularly for auto launched flows, these techniques are often insufficient.

Flow error
Answering why this failed doesn’t have to be a rabbit hole.

Debug log to the rescue!

Thankfully Salesforce has made a few updates over the years that makes viewing the internal state of flow a little easier. Particularly one can see variable assignment, loop behaviour and more detailed error logging. 

The debug log is a veritable garden of detail about the internal state of Salesforce, including info about:

  • Database Changes
  • Workflow ( Workflow rules, Assignment rules, Approval processes, Process builder, visual workflow)
  • Validation
  • Callout (such as HTTP callouts)
  • Apex Code
  • Apex Profiling (used to show limits while running apex)
  • Visualforce
  • System

In the debug log you will see messages grouped into the above log categories.  These log categories each have a adjustable level of detail. Meaning one can tune the logging that takes place in order in order to get a uncluttered log. Workflow is the log category that we are most concerned about when troubleshooting flows and process builder.

Something that I failed to understand about debug logging for a long time is that the logging is driven by individual user’s actions. One can manually set a log trace to follow the actions of more than one user at a time, however in practice it is very difficult to log the events of more than a few users at a time within Salesforce.

Salesforce Makes Debugging Easy

Fortunately Salesforce has done something clever to make setting a user log trace very quick and easy. The system will automatically set a debug logging level for your user whenever you open the debug console. This means debug setup is easy as opening up the developer console, then making making one adjustment within Salesforce setup.

Debug levels
Opening the dev console will create the “SFDC_DevConsole” debug log level .

The different debug log level options are:

  • None
  • Error
  • Warn
  • Info (Default for workflows when using the native dev console logging level)
  • Debug
  • Fine
  • Finer
  • Finest

Notice the default logging level for the Workflow log category, it’s set to ‘Info’. Changing these log levels adjusts how much detail is captured for each log category. ‘Info’ covers some of what we need for flows and process builder but it’s lacking the most useful actions. See the table at the bottom of this post for all the available actions. For example to see when and how a flow is completing a variable assignment,  one needs to adjust the level to ‘finer’.

1. First Time Logging Setup

  1. Open the Developer Console.
    1. This will begin logging for your user for 30 minutes.
  2. Go back to your main Salesforce window and navigate to SF classic: Setup Quick Search –> ‘Debug level’.
  3. Edit the SFDC_DevConsole logging level.
    1. Opening the dev console created this logging level, now let’s adjust it be appropriate for your needs.
  4. Slowly dial up the level of logging from ‘info’ to higher levels of logging and observe which different actions are shown.
  5. I would suggest starting with workflow on ‘finer’, adjust as needed.
Use SF Classic debug level page to quickly see what will be logged.

2. Log That Automation

Once you have the debug level set- your tooling is all ready, it’s time to actually troubleshoot. Given that the native debug logging captures for your own user and only your user, you need to fire your automation. This can happen by any of the following ways:

  • Complete the triggering actions within SF to trigger the automation.
  • If your process is an auto launched flow consider the ‘execute’ button.
  • For process builders and auto launched flows one can write and run tests. Test driven development has many advantages, getting access to logging quickly is just one of the many.


3. Find that Bug:

View Logs and Quick Edit Logging Levels

To understand how to view your logs after executing your automation please see this trailhead, it has a great explanation of how to view your log files. It also covers how to adjust logging levels within the dev console itself, which is a real time saver. The first time setup above is useful to understand the logging levels as a concept but is a little clunky to navigate on a day to day basis. 


4. Don’t Overlook Performance

Keep in mind that logging isn’t completely free, there are some consequences when using these tools. Logging will consume CPU time, if you are using this tool to troubleshoot performance know that this logging will consume some of your execution limits.

There is a 2MB file size limits on any single log. Turning everything to ‘Finer‘ is a recipe for trouble to overrun that file size. Only log what you need, I have yet to run into a scenario where I need super detailed debugging across all categories at once.

Reference: Workflow Log Event Types

The bolded actions are those that are not covered by the default ‘info’ debugging level.

Event Name Fields or Information Logged with Event Level Logged
FLOW_ACTIONCALL_DETAIL Interview ID, element name, action type, action enum or ID, whether the action call succeeded, and error message FINER and above
FLOW_ASSIGNMENT_DETAIL Interview ID, reference, operator, and value FINER and above
FLOW_BULK_ELEMENT_BEGIN Interview ID and element type FINE and above
FLOW_BULK_ELEMENT_DETAIL Interview ID, element type, element name, number of records, and execution time FINER and above
FLOW_BULK_ELEMENT_END Interview ID, element type, element name, and number of records FINE and above
FLOW_CREATE_INTERVIEW_BEGIN Organization ID, definition ID, and version ID INFO and above
FLOW_CREATE_INTERVIEW_END Interview ID and flow name INFO and above
FLOW_CREATE_INTERVIEW_ERROR Message, organization ID, definition ID, and version ID ERROR and above
FLOW_ELEMENT_BEGIN Interview ID, element type, and element name FINE and above
FLOW_ELEMENT_DEFERRED Element type and element name FINE and above
FLOW_ELEMENT_END Interview ID, element type, and element name FINE and above
FLOW_ELEMENT_ERROR Message, element type, and element name (flow runtime exception) ERROR and above
FLOW_ELEMENT_ERROR Message, element type, and element name (spark not found) ERROR and above
FLOW_ELEMENT_ERROR Message, element type, and element name (designer exception) ERROR and above
FLOW_ELEMENT_ERROR Message, element type, and element name (designer limit exceeded) ERROR and above
FLOW_ELEMENT_ERROR Message, element type, and element name (designer runtime exception) ERROR and above
FLOW_ELEMENT_FAULT Message, element type, and element name (fault path taken) WARNING and above
FLOW_INTERVIEW_PAUSED Interview ID, flow name, and why the user paused INFO and above
FLOW_INTERVIEW_RESUMED Interview ID and flow name INFO and above
FLOW_LOOP_DETAIL Interview ID, index, and value

The index is the position in the collection variable for the item that the loop is operating on.

FINER and above
FLOW_RULE_DETAIL Interview ID, rule name, and result FINER and above
FLOW_START_INTERVIEW_BEGIN Interview ID and flow name INFO and above
FLOW_START_INTERVIEW_END Interview ID and flow name INFO and above
FLOW_START_INTERVIEWS_ERROR Message, interview ID, and flow name ERROR and above
FLOW_SUBFLOW_DETAIL Interview ID, name, definition ID, and version ID FINER and above
FLOW_VALUE_ASSIGNMENT Interview ID, key, and value FINER and above
FLOW_WAIT_EVENT_RESUMING_DETAIL Interview ID, element name, event name, and event type FINER and above
FLOW_WAIT_EVENT_WAITING_DETAIL Interview ID, element name, event name, event type, and whether conditions were met FINER and above
FLOW_WAIT_RESUMING_DETAIL Interview ID, element name, and persisted interview ID FINER and above
FLOW_WAIT_WAITING_DETAIL Interview ID, element name, number of events that the element is waiting for, and persisted interview ID FINER and above

Thomas George is a Freelance Salesforce Administrator/ Developer. For two years he has been helping businesses solve problems with Salesforce.

Published by


I am a Freelance Salesforce Admin/ Developer, have been working on the platform for the last 2 years helping businesses solve problems. If you are interested in collaborating don't hesitate to reach out.

Leave a Reply