Flows

Introduction

Salesforce Flows are a game-changer for automating business processes without writing a single line of code. However, like any powerful tool, they can become intricate, making debugging and monitoring a challenge. Enter Pharos Triton – your Flow's new best friend for logging. Let's dive into how you can supercharge your Flows with custom logging using the Triton framework.

Why Triton Logging for Flows?

Once of the big advantages to using Flows is the ability to utilize Apex code. This technique really opens up a whole world of possibilities. We won't spend too much time here describing the intricacies of Invocable Apex. For more information on what these are all about, please refer to the Salesforce documentation.

While Flows are excellent for orchestrating processes, tracking their execution and diagnosing issues can be tedious. Triton provides an invocable Apex action that seamlessly integrates with Flows to create detailed log records. This integration ensures that every step of your Flow is transparent and traceable.

Setting Up Triton Logging in Your Flow

Let's walk through a simple example: a Partner Intake Screen Flow. This flow captures data through a form and, based on the partner type, assigns a lead score before creating a lead record.

Step 1: Add the First Triton Apex Action

To enable logging, you need to add the Triton Apex action to your Flow. It's best practice to add your logging action as the very first element in the flow. This ensures a log is always created, even if the flow fails at a later step. Additionally, this setup establishes log grouping, allowing any subsequent logs to be related to our initial log.

1. Click (+) and the "Action" element onto the canvas.

1. Search for "triton" and select the Add Log action

Step 2: Configure the Log Parameters

Once the Triton action is added, you need to configure its parameters:

1. Label your log action, e.g., "Log Partner Intake Start".

2. Set the required parameters

Key Parameters Explained

• Area: Represents the functional area (see Area enum), e.g., Accounts, Opportunities. This value conveys a business or data-centric description of functionality.

• Category: Best left as Flow for most logging purposes. This is one of the predefined Category enum values that determines how Pharos displays your log records. If an invalid category is provided, it will default to Flow.

• Type: Indicates the technical classification (see Type enum), such as: Autolaunched Flow, Screen Flow. Provides a more specific technical classification of the log.

• Summary: A brief description of the log entry.

• Details: Detailed information that includes any relevant context variables, record ids or other data that the flow is utilizing to make decisions.

• Level: Logging level for this log action (see Level enum). Controls the verbosity of logging output, ranging from ERROR to FINEST. Defaults to INFO if an invalid level is provided.

• Flow API Name: Api name of this flow.

• Interview GUID: A unique identifier for the Flow instance. Use $Flow.InterviewGuid for consistency.

• Operation (Optional): Name of the operation being performed.

• Transaction ID (Optional): Can be used to explicitly group related logs together. If provided, will resume an existing transaction instead of creating a new one.

• Stacktrace (X-Ray Machine Only): Current stacktrace information for error tracking. This parameter is automatically supplied by the X-Ray machine.

• Full Stacktrace (X-Ray Machine Only): Complete stacktrace including previous traces, useful for error propagation. This parameter is automatically supplied by the X-Ray machine.

Special attention to one key parameter: the Interview GUID. This parameter represents an ID of the currently running Flow instance. We recommend that you always pass this value along by using the $Flow.InterviewGuid global variable. This will allow Pharos Triton to link up Flow failures to your custom logs and provide enhanced post-processing information including:

• Stack traces for error tracking

• User information

• Related object details

• Installed package information

• Pending jobs in the flow queue

• Total active session information

More details on this can be found in the next section.

Utilizing Constants for Common Log Parameters

To maintain consistency and simplify updates across all your logging actions, it's recommended to create constants for your log parameters. Define constants for parameters like Area, Category, Type These parameters should remain consistent across your logging actions. Adopting a consistent naming convention is key. In our example, we're prefixing all log-related resources with Log or Log_ for quick and easy filtering in the toolbox

Using constants is crucial, even in small Flows. Consider our example Flow with just 4 log actions - changing the Area parameter would require updating 4 separate locations without constants. With constants, you only need to update one place.

Utilizing Text Templates for Log Details

The Details parameter plays a crucial role in effective troubleshooting and debugging. When crafting your log details, include all relevant contextual information such as:

• Record IDs

• Decision variables

• User inputs

• Any data that influences flow execution

Text templates are the perfect tool for combining static text with dynamic data in your logs. While each log's details will vary, templates help you maintain consistent, well-formatted messages throughout your flow.

Step 3: Implement Logging Throughout Your Flow

With our initial log action in place, it's time to add logging throughout the rest of the flow. While you can clone and paste your existing log action, we recommend creating fresh log actions each time. This approach helps avoid common issues that can arise from cloning, such as confusing element names or incorrect parameter mappings.

Strategic placement of log actions is key. Here are the critical points where you should consider adding logs:

1. Start of the Flow: Capture the flow's initiation and any input parameters

2. User Interactions: Record form submissions, screen inputs, and user decisions

3. Data Operations: Log before and after any DML operations, callouts, or data transformations

4. Decision Points: Document which branch of logic the flow is following

5. Error Handling: Add detailed logging in fault paths to aid troubleshooting

Step 4: Viewing the Log Output

Let's examine what our logging looks like in action. We'll run our Partner Intake flow, which we've configured to fail during lead creation to demonstrate error handling.

When you navigate to the Partner Intake Flow Start log, you'll see a comprehensive view of the flow's execution:

Each log entry is interactive - clicking on one reveals the detailed information we configured in our log actions, including any custom parameters and context we added:

When you open this error log entry, you'll access the standard Pharos flow debug view. This powerful interface breaks down every aspect of the flow's execution, from its current state to error details and decision pathways.

Pass Additional Log Fields (Optional)

If you need to log additional information, use the "Additional Fields" parameter:

1. Create a JSON map using a Text Template resource.

2. Pass this JSON map to the "Additional Fields" parameter.

Best Practices

• Strategic Placement: Add logs at critical points - flow start, before/after DML operations, decision points, and error paths

• Use Constants: Maintain consistency by using constants for common log parameters like Area, Category, and Type

• Use Text Templates: Create formatted detail messages that combine static text with dynamic flow data

• Consistent Naming Conventions:

  • Prefix log actions with "Log_"

  • Prefix constants with "Log_"

  • Prefix text templates with "Log_Details_"

• Interview GUID: Always pass $Flow.InterviewGuid to ensure proper log grouping and error tracking

• Detailed Context: Include relevant record IDs, user inputs, and decision variables in your log details

• Additional Fields: Use JSON-formatted additional fields to capture extra contextual data when needed

• Error Handling: Add comprehensive logging in fault paths to aid troubleshooting

Conclusion

Integrating Triton logging into your Salesforce Flows transforms them from black boxes into transparent, easily debuggable processes. The combination of strategic log placement, consistent naming conventions, and automated error capture creates a robust monitoring system that makes maintenance and troubleshooting straightforward.

By following this guide's best practices, you'll create Flows that are not only powerful automation tools but also self-documenting and easy to support. Whether you're building simple screen flows or complex auto-launched processes, proper logging will be your ally in maintaining and evolving your solutions. Happy Flowing – with the power of Triton logging at your command!