Tips for Using ACP Actions in Flows

​

Introduction

​

1. Robust Error Handling

• Check Success Flags: If your ACP Invocable Action returns a success boolean output parameter (highly recommended), always check its value using a Decision element immediately after the Action.
  • Outcome 1 (Success): Proceed with the normal Flow logic.
  • Outcome 2 (Failure): Route the Flow to an error handling path.
• Utilize Error Messages: Ensure your ACP action returns a descriptive errorMessage string output when success is false. Log this message or display it to a user if appropriate.
• Use Fault Paths:
  • Connect a Fault Path from your ACP Action element to a subflow or a series of elements designed to handle unexpected errors (e.g., if the Apex action itself throws an unhandled exception).
  • Within the fault path, you can access the {!$Flow.FaultMessage} global variable to get details about the error.
• Notify Admins or Log Errors: In your error handling path, consider:
  • Sending an email notification to a Salesforce Admin.
  • Creating a custom Log record (e.g., ACP_Error_Log__c) with details like Flow name, Action name, input parameters (be mindful of sensitive data), and the error message.
  • Posting an error message to a dedicated Slack channel for monitoring.

(Placeholder image for Flow error handling path)

​

2. Managing Input and Output Parameters

• Use Flow Variables: Store outputs from ACP actions in Flow variables. This makes the data accessible to other elements in your Flow.
• Text Templates for Complex Inputs: For constructing complex string inputs (like formatted messages or JSON payloads), use Text Templates. They allow you to combine static text with Flow variables and record fields.
• Formulas for Transformations: Use Flow Formula Resources to transform data before passing it as input to an ACP action or to process its output.
• Apex-Defined Data Types: For complex input or output structures, consider using Apex-defined data types as variables in your Flow. Your Invocable Method can then accept or return instances of these Apex classes, providing a structured way to handle complex data.
  • Ensure the Apex class has an @AuraEnabled constructor and @AuraEnabled public members for Flow compatibility.

​

3. Bulkification and Performance

• Avoid ACP Actions Inside Loops (If Possible): Placing an Action element (which often performs a DML operation or callout) inside a loop that iterates over many records can lead to hitting governor limits (e.g., too many SOQL queries, DML statements, or callouts).
• Bulkify Your ACP Actions: If your ACP Invocable Method needs to process multiple items, design it to accept a List of inputs and perform operations in bulk.
  • Example: Instead of sendMessage(String channelId, String messageText), use sendMessages(List<MessageRequest> requests), where MessageRequest is an Apex class holding channelId and messageText.
• Collect Records, Then Process: If you need to call an ACP action for multiple records:
  1. Loop through your records and collect the necessary data into collection variables.
  2. After the loop, pass these collections to a bulkified ACP action.

​

4. Debugging Flows with ACP Actions

• Use Flow Debugger: Salesforce Flow Builder’s debugger is invaluable.
  • Run the Flow in debug mode and inspect the input and output values of your ACP Action element.
  • Check “Run flow in rollback mode” to prevent DML operations from being committed during debugging.
• Check Apex Debug Logs: If the ACP action is failing within the Apex code, enable debug logs for the running user (often the Automated Process user for record-triggered flows) to see detailed execution logs from your Invocable Method.
• Isolate the Issue: Temporarily simplify the Flow or the inputs to the ACP action to pinpoint whether the issue is in the Flow logic, the data being passed, or the ACP action’s Apex code itself.
• Log Inputs/Outputs: During development, you can temporarily add “Create Records” elements to log the inputs being sent to your ACP action and the outputs received from it to a custom object for inspection. Remove these before activating in production.

​

5. Naming and Descriptions

• Clear Labels for Actions: In your @InvocableMethod(label='...') annotation, use a clear, descriptive label that indicates the system and the action (e.g., “ACP Slack: Send Message”, “ACP Jira: Create Issue”). This label appears in Flow Builder.
• Descriptive Variable Names: Use clear API names for your Flow variables that store inputs or outputs for ACP actions (e.g., slackChannelIdInput, jiraIssueCreationResponse).
• Document in Descriptions: Utilize the “Description” field for your Flow, Action elements, and variables to explain their purpose, especially how they relate to ACP.

​

6. Security and Callout Considerations

• Named Credentials: Prefer Named Credentials for authenticating to external services called by your ACP tools. This avoids hardcoding credentials in Apex or Flow.
• User Context: Be aware of the user context in which the Flow runs. Record-triggered flows often run in system context. If your ACP action relies on a specific user’s permissions for an external system, ensure the integration user or the Named Credential principal has the necessary access.
• Callout Limits: Remember that Salesforce has limits on the number and duration of callouts per transaction. Design your ACP actions and Flows to be efficient.