You are here:
Error Handling in Flow Approval Processes
Error handling addresses how to manage unexpected issues that can occur when a flow approval process runs. Configure fault paths for stages to define actions to take if issues occur, ensuring that approval submissions are approved or rejected instead of failing.
Required Editions
| View supported editions for Flow Approval Processes. |
General
If an orchestration run associated with a flow approval process encounters an error, it fails. This failure sets the status of the associated parent approval submission to Error. Unlike other orchestration runs, an orchestration run associated with a flow approval process can’t be resumed.
When an orchestration run associated with a flow approval process fails, Salesforce sends an error email to either the admin who last modified the flow approval process or to the Apex exception email recipients. The error email provides details about the flow approval process, including the executed elements and all flows referenced by its steps. For an active flow approval process, the email also includes a link to view the failed orchestration run's details in Flow Builder. If a flow called by the orchestration run causes the failure, recipients receive two error emails: one for the flow approval process failure and one for the called flow's failure.
To manage errors, configure fault paths for stages in your flow approval process. These paths define alternative actions to take if a stage or any step within it encounters an error, which helps minimize process failures.
Design and debug your flow approval processes in a sandbox environment before deploying them to production, as a failed approval submission does not necessarily roll back all prior record changes.
Unhandled Errors and Approval Submission Status
An unhandled error occurs when an automation encounters a problem during execution, and no recovery mechanism exists. For an orchestration run associated with a flow approval process, an unhandled error occurs when a stage or step within a stage encounters an error, and the stage has no configured fault path.
| Associated item | State | status |
|---|---|---|
| Approval submission | Any error occurred | Error |
| Orchestration run | Any error occurred | Error |
| Stage run | An orchestration run-level error occurred | Discontinued |
| Stage run | The stage or a step within the stage caused the error | Error |
| Step run | The step within the stage caused the error | Error |
| Step run | The step within the stage didn’t start before the error occurred | Not Started |
| Step run | The step within the stage was in progress when the error occurred | Discontinued |
| Approval work item | The approval work item had been completed before the error occurred |
|
| Approval work item | The approval work item had been assigned, but not completed before the error occurred | Assigned |
Error Handling Strategies for Flow Approval Processes
Error handling in a flow approval process primarily aims to minimize failures in associated orchestration runs so that parent approval submissions are approved or rejected. Use fault paths to manage errors from stages and steps. You can use an individual fault path or a centralized fault path in a flow approval process.
Any fault path can contain decision elements and stage elements. The stage elements in a fault path can contain background steps and approval steps. A fault path can also use go to connectors. A go to connector in a fault path can connect to another element in the fault path, an element in another fault path, or an element in the main path of the flow approval process.
Individual Fault Paths. Configure a separate fault path for each stage in a flow approval process. These individual paths contain elements and stages with steps that manage errors specific to each stage. This approach provides highly localized error resolution. For example, if a stage contains only one approval step, the fault path determines whether the approval step is approved or rejected. If the approval step is approved and no additional approvals are necessary, connect the decision outcome to the stage that runs final approval actions. If the approval step is approved, but more approvals are required, connect the decision outcome to the next flow approval process stage containing approval steps. If the approval step is rejected, connect the decision outcome to the stage that runs final rejection actions.
Centralized Fault Path. Configure one central fault path that serves as a consolidated error handling mechanism. Typically, this approach starts with a decision element that evaluates variables and automatic output related to the orchestration run to identify the specific stage where the error occurred and what to do to address the failure. Connect the fault paths from other stages to the first decision element in the central fault path. This approach provides comprehensive error resolution. For example, in a multistage approval process, the centralized fault path begins with a decision element. If the status of the “Perform Initial Review” stage hasn’t been completed, the decision outcome’s path includes a stage with a background step that automatically notifies the submitter about the issue. Conversely, if the “Get Initial Financial Approval” step in the “Process Financial Approvals” stage failed, the decision outcome’s path includes a stage with two steps: a background step and an approval step. The background step notifies the finance department of the failure. The approval step assigns an alternate approval to the finance group. Because the finance approval is the last required approval in this approval process, this outcome path then connects to the decision element that determines whether to run final approval actions or final rejection actions.
Avoiding Fault Path Auto-Approvals
If a stage without a fault path or one of its steps fails, the orchestration run fails, and the status of the associated approval submission is set to Error. If a stage with a fault path or one of its steps fails, and the fault path runs without error, the status of the associated approval submission is either Approved or Rejected. The final status of the approval submission depends on the scenario.
| Error Scenario | Final Approval Submission Status |
|---|---|
| The stage where the error occurred has no configured fault path. | Error |
| The stage where the error occurred has a configured fault path that runs without error. All completed approval work items are approved. | Approved |
| The stage where the error occurred has a configured fault path that runs without error. At least one completed approval work item is rejected. | Rejected |
| The stage where the error occurred has a configured fault path that runs without error. There are no completed approval work items. | Approved |
To avoid automatically approving an approval submission with no completed approval work items, use these guidelines:
- Configure fault paths for stages only when a previous stage contains at least 1 approval step. For example, a flow approval process starts with a stage containing only a background step that locks the record to be approved. Don’t configure a fault path for this stage. The most likely reason for this stage to fail is that the record is already locked.
- Configure a fault path for the first stage that contains approval steps to determine whether any approval work items have been completed. In the decision outcome path where no approval work items have been completed, add a stage with an approval step.
Error Handling Limitations
- When an orchestration run associated with a flow approval process encounters an unhandled error, the orchestration run can’t be resumed.
- There’s no way to reject an approval submission if a fault path finishes without an error and no approval work items have been completed.
- No error handling can be added for orchestration-run level errors.
- Debug details for a failed orchestration run can be viewed only within 14 days of the failure.
- If an approval submission fails, Salesforce doesn’t necessarily roll back any record additions, changes, or deletions that occurred before the associated orchestration run failed.
