Salesforce FlowLog

Admins sometimes wonder if their work is being used effectively. Salesforce FlowLog is a great solution. While it’s easy to track whether fields are being filled out or new records are being created, many of the things built—such as background flows that automate processes—are harder to measure. These automations often run behind the scenes, making their impact less visible.

Building, testing, and debugging automations can be challenging, even with the improvements in Flow Builder. Sometimes visualizing the process within a flow can be difficult. In screen flows, it’s possible to add interstitial screens to display variable values or messages to track progress. However, in record-triggered flows, which operate invisibly during or before record saving, tracking what’s happening becomes more complex.

To address this, some admins use Chatter posts, either on created or updated records or tagged to a special Chatter Group for aggregation:

A Chatter Group page showing a post indicating a contact was updated by the Skyvia integration user.

Tasks can also be used for tracking, as they are easy to create and relate to updated records:

Classic contact page with an image formula displaying the organization’s logo and status.

While these methods are useful for debugging, they are not ideal for reporting on flow activity or capturing structured data.

Introducing FlowLog

To address these limitations, a custom object called “FlowLog” was created specifically for logging flow activities. This object includes fields for the flow name, version, step, and notes. The records are auto-numbered for easy sorting by creation time.

Once the FlowLog object was set up, adding a Create Record step in any flow became straightforward:

Assignment step setting values for FlowLog record.

Easier with a Subflow

To simplify the process further, an autolaunched flow was created and named “FlowLog.” This subflow can be included in other flows to log steps along the path or different decision paths:

A flow canvas showing the FlowLog subflow used at different decision points.

Avoiding Redundancy

Rather than recreating the custom object and subflow for each new client, it is more efficient to store and install these elements multiple times. Three main methods to achieve this are:

Unmanaged Package An unmanaged package can be created and installed in client orgs, allowing modifications as needed. However, it appears in the Setup > Installed Packages section, which might be confusing for admins who mistake it for a commercial package.
Metadata Deployment Metadata can be deployed using Change Sets or tools like Copado and Gearset. This method integrates the elements as if they were built directly in the client org, without the confusion of an unmanaged package listing.
Code Repository Storing metadata in a code repository like GitHub and deploying it using SalesforceDX or CumulusCI (CCI) allows for collaboration, version control, and easy backup. This method requires familiarity with command-line tools and GitHub but offers flexibility and the ability to quickly set up clean scratch orgs.

File viewer in VisualStudio Code displaying FlowLog object, fields, and flow definitions.

Salesforce FlowLog

None of these solutions are groundbreaking, but they offer practical approaches anyone can use. Creating a FlowLog object similar to the one described is encouraged. Sharing a public GitHub repo might seem too straightforward, so exploring and setting up these solutions independently is recommended.

Now, equipped with these ideas, it’s time to get hands-on with Salesforce Setup. ⚙️