Syracuse Developers

A Salesforce Community Group

FlowDebug

The lightweight, simple way to print debug statements and governor limits from Flows

Have you ever wanted to print a simple debug statement inside a flow? Clicking the Debug button works, but has its limitations. This is especially true when trying to test out end to end functionality and you have multiple automations firing off.

FlowDebug is a simple utility that let's you output any text string to the debug logs, as many times as you'd like. As an added bonus, you can also capture how close you are to exceeding the governor limits at any point within your flow.

This utility works for any flow that allows for Actions. This includes After Save (Actions and Related Records) Record Triggered Flows, Screen Flows, Scheduled Flows, Platform Event Triggered Flows and Autolaunched Flows (No Trigger). Unfortunately, Before Save (Fast Field Update) Record Triggered Flows do not support this.

This is the simplest way to install the package. Log into Salesforce. Replace everything after your instance's domain name with the following:

/packaging/installPackage.apexp?p0=04t4x0000006cVU

As all the code does is print to the debug log, so it doesn't really matter if you pick install for admins or all users. All this choice will do is enable Apex Class Access for the FlowDebug apex classes.

Click Install. After a few moments, the package is installed and you're ready to go. You can do this in a sandbox or production.

You can also install this utility manually. Download the metadata here.

If you have sfdx, you can load the package with sfdx force mdapi deploy -w 1 -f FlowDebug.zip

To install and run the unit tests, use sfdx force mdapi deploy -w 1 -f FlowDebug.zip -l RunSpecifiedTests -r FlowDebugTest

Otherwise, extract the zip file. In Setup, search for Apex Classes. Click the New button. Copy and paste the FlowDebug.cls file into the editor, and save. Repeat for the FlowDebugTest.cls file. You can now use change sets to move these two classes to other instances.

Using sfdx, you can deploy to a sandbox or production. Installing manually, you'll need to deploy to a sandbox first and then move to production via a change set.

To output a debug statement, first add an Action element.

For auto layout, click the plus symbol in-between an element and scroll down until you find Action. Starting in Winter 23, you will have a search box, where you can just search for 'debug'.

For freeform layout, find the Action in the toolbox on the left and drag it onto the canvas.

Search for FlowDebug and select it

Aside from the standard label, API name and description fields, you need to set your input variables. All 3 are optional, but you really need to set at least one in order to get anything printed out.

Log Prefix - The debug log will show the prefix followed by your message or governor limits. Debug logs can get to be quite large, so you can use this prefix value to help search for your entries. This is especially handy if you're writing several debug log entries within the same flow, or if this flow could be part of a bulk update. We suggest putting values like your name, the flow name or the record id in this field. You can also use a text constant or variable in this field to help ensure consistency. We used a constant called DemoFlow in the above screenshot.

Show Governor Limits - If you set this to {!$GlobalConstant.True}, we will output your current governor limits, whatever they were when you used this action. You can do this multiple times within your flow, and track how your usage is growing as the flow proceeds. These debug statements will keep firing off until you cross the governor limit, even if your flow ultimately fails and is stopped.

Statement - Anything you put in here will be printed to the debug log. You can use this in combination with the showing governor limits if desired.

From the developer console - This is a good option when you're actively going to do something that will make the flow fire off as you (not a platform event flow). Go to the gear icon in the upper right and select Developer Console. At the bottom, click the Logs tab. You'll see log entries created as you use the system. Fire off your flow, then double click the logs. You may need to look through a few of them. You can use the Debug Only and Filter checkboxes to find your log entries. This is where the Prefix can come in handy, especially with bulk operations.

From setup - This is a good option when you want to debug someone besides yourself, or if you need to monitor the automated process user activities (such as debugging platform event flows). In setup, search for Debug Logs. Click New. Select the user you want to debug, how long to debug for, and a debug level. The level doesn't matter too much, as long as you select an Apex Code level of Debug, Fine, Finer or Finest. To debug code running as the automated process user, change the traced entity type to Automated Process. Save and run your flows. The debug logs can now be downloaded or viewed.



The built in default of SFDC_DevConsole works just fine, but can output a lot more information than you need. If you want to go really minimal, create a new debug log level where Apex Code is set to Debug and all other values are set to None.

You can get the definitive information on governor limits here, but this is a simplified overview of the ones we report upon. Remember, most of these limits are shared with Apex code and managed packages. This isn't an exhaustive list, so other limits may apply.

SOQL Query Limit - Every time you do a Get Element, it uses up a SOQL query.

SOQL Query Rows Limit - Number of records that were retrieved from SOQL queries (Get Elements).

DML Statement Limit - Every time you do a Create, Update or Delete, it uses up a DML statement.

DML Rows Limit - Number of records that were written via DML statements (Create, Update or Delete Elements).

CPU Time Limit - Amount of CPU time used. Everything you do in Apex or Flows uses a little bit of CPU time.

Heap Size Limit - Amount of memory used. Every variable and record stored in Apex or Flows uses a little bit of memory.

Email Invocation Limit - Number of times you tried sending emails. This is different than the total number of emails actually sent out.

Before you uninstall this utility, you must remove the action element from all your flows. Unfortunately, if it's referenced in an older version of your flow, you must also delete the old versions too.

If you installed the unmanaged package, you can go to Setup - Installed Packages, and click the Uninstall button next to FlowDebug.

If you installed manually, go to Apex Classes. Find the FlowDebugTest class and click Del. Then, find the FlowDebug class and click Del.

Although we cannot necessarily help with fixing your flows, please reach out to us if there are any problems in using this utility. Send email to mdemaria@SyracuseDevelopers.com

While you're here, be sure to check out our Certification Exam calculators as well as future community meetup events

And be sure to take a look at the Trailblazer community's cookbook, Foodforce for Good: The 101 plant-based deliciousness of the world