Definition

The Error Handling feature allows users to effectively manage, respond to, and resolve errors that occur during flow execution. It provides a structured way to handle both expected and unexpected issues at different levels—whether within individual actions or across the entire workflow.

Key capabilities include:

• Action-level error handling: Manage failures in specific steps.
• Global error handling: Centralized management of flow-wide issues.
• Manual options: Features like Rerun and Retry give users control to reprocess failed steps or flows.
• Advanced strategies: Trigger responses (e.g., send notifications, apply conditional logic) based on error events, such as integrating with email arrival or branching flows when an error occurs.

This powerful system ensures workflows remain reliable, transparent, and resilient—even when things go wrong.

Systematic Error Handling

Zenphi supports automatic error management through two main methods: Action-Level Error Handling and Global Flow Error Handling. These options let you decide how to respond when parts of a flow fail—whether to retry, continue, or alert someone.

Action-Level Error Handling

This applies to individual actions within your flow. Most actions have an Error Handling tab in their settings, allowing you to define how Zenphi should behave if that specific action encounters an error.

Access Point: Click the gear icon next to the action and navigate to the Error Handling tab (last tab).

Available Settings:

1. Retries: Set how many times Zenphi should retry the action after it fails, and how long to wait between each attempt. This is ideal for temporary issues like slow APIs or timeouts.

2. Behavior on Error: Choose what Zenphi should do after retries are exhausted:

• Fault the Flow: Stop the entire flow.
• Continue: Skip the failed action and move to the next one.

Example: You are updating a Google Sheet. If the service is temporarily unavailable, you can retry the action 3 times, waiting 5 minutes each time. If it still fails, you can choose to either continue the flow or stop it completely.

Global Flow Error Handling

This acts as a safety net when something goes wrong that isn’t caught at the action level. It is configured at the workspace level and applies to any flow published under that workspace.

Access Point: Click the gear icon in the bottom-left of the Zenphi dashboard and select Flow Error Handling.

Available Settings:

• Email Notifications: Add one or more email addresses to receive notifications when a flow fails and wasn’t handled at the action level.
• Recipients: You can notify the flow publisher by default or specify additional recipients like team leads or admins.

Example: If a flow for processing employee onboarding fails at a critical point, Zenphi will send an email with details to the assigned contacts, ensuring the failure doesn’t go unnoticed.

Manual Error Handling

Manual error handling in Zenphi gives you direct control over how to respond when a flow run fails. From the Recent Runs section, you can monitor run statuses, review what went wrong, and choose to either Rerun or Retry the flow depending on the situation.

Accessing Recent Runs

To manage failed or completed runs:

1. Navigate: In the left-hand menu, click the gear icon and select Recent Runs.

2. View List: This page shows a list of your most recent flow executions.

3. Filter: You can filter runs by Status (Executing, Completed, Faulted, Canceled, Skipped), Start Time, or Flow Name.

Tip: If you open a specific flow and click into its Recent Runs, the list will be automatically filtered to show runs from that flow.

You can select one or more runs from this list. Once selected, two main options appear: Rerun and Retry.

Understanding Flow Versions

Each flow in Zenphi has a version number formatted as X.Y, where X is the published version, and Y is the number of changes saved after publishing.

• Publishing: Increases the number before the dot (e.g., from 2.1 to 3.0).
• Saving: Increases the number after the dot (e.g., from 3.0 to 3.1).

Only published versions (X) are used for flow executions. Versions like 4.0 and 4.5 will run the same way unless 4.5 is published as version 5.0.

This distinction is critical when choosing between Rerun and Retry, as Zenphi refers to the version used in the original run or the latest published one depending on the option selected.

Rerun vs. Retry

Rerun

• Starts the flow from the beginning, using the latest published version.
• Useful when: You have made changes to fix the issue or you want the flow to run under updated logic.
• The old run stays in history, and a new run begins based on the current published version.

Retry

• Resumes the same run from the step where it failed.
• Keeps the original version number (does not use any changes made after the failure).
• Useful when: The failure was caused by an external issue (e.g., server down, API error) and the flow’s structure didn’t need changing.

Advanced Error Handling

Sometimes, basic retries and email alerts aren’t enough. For more flexible and powerful responses to errors, Zenphi supports advanced error handling. This allows you to build automated recovery logic or custom responses within your flows.

There are two key ways to implement advanced error handling in Zenphi:

Triggering Automation from Global Flow Errors

When a flow fails (even after retries), Zenphi can notify you by email. By connecting that global error alert to a Zenphi Mail trigger, you can start a new automation flow in response to any failure.

How it works:

1. Create a Flow: Create a new Zenphi flow with the Zenphi Mail trigger.

2. Configure Settings: Set up Global Flow Error Handling to send emails to the specific address in the trigger.

3. Automate Response: Configure this flow to listen to the error emails and respond as needed.

For more detail and an example of this in action, see this post: Advanced Error Handling with Zenphi Mail Trigger

Using Boolean Outputs to Branch Logic on Errors

When configuring Action-Level Error Handling, if you choose to Continue on Error, Zenphi adds a Boolean field to the action’s output—typically named like Step Errored.

This output helps you check if the action failed, and based on that, take different actions in your flow using an If Condition.

How it works:

1. Settings: In the action settings, set Behavior on Error to Continue.

2. Condition: In the next step, add an If Condition that checks the Boolean output.

3. Logic: Based on whether the action failed (true) or not, direct the flow to different logic paths.

Example Use Cases

Here are real-world scenarios where advanced error handling helps recover or adapt:

• PDF Merge Fails: Check if all input files are PDFs. If not, automatically convert them using the Convert to PDF action before retrying the merge.
• Null or Missing Data: If a required parameter is empty and caused the error, send a Request Data action to the manager or team member to provide the missing value.
• Notify When Errors Occur: If any step fails, automatically generate a Google Doc with failure details and send it via Google Chat or email to notify your support or IT team.
• API Integration Timeout: If a webhook or external API fails, wait 5 minutes, then retry the same step—or route the flow to a fallback action.
• Smart Retry Paths: Use advanced If-Else conditions to retry with alternate settings or credentials if the first attempt fails.

Example Scenario: Automated Processing for PDF Merge

Scenario: You are running an automated flow that merges several uploaded documents into a single PDF using the Merge PDF action. Occasionally, the merge fails—either because one of the files isn’t in PDF format, or a file is missing altogether.

You want to handle this gracefully, without stopping the flow, and try to fix the issue automatically.

Configuration Steps:

1. Configure the Merge PDF Action: In the Error Handling tab, set Retries to 3 attempts (1 minute, 10 minutes, 1 hour). Set Behavior on Error to Continue. This enables the action’s HasErrored output for further logic.

2. Add an If Condition: Check if MergePDF.Step Errored is true. If it is, route to a recovery branch in your flow.

3. In the Recovery Branch: Use a Loop to check each file’s format. If a file is not a PDF, run a Convert to PDF action. After converting all non-PDF files, retry the Merge PDF action again with the cleaned file list.

4. Still Failing? Ask for Help: If the second merge attempt also fails, use a Request Data action to ask the team lead to re-submit missing or correct files, attaching the original error message.

5. Log and Notify: Create a Google Doc summarizing what failed, what recovery steps were taken, and who was contacted. Automatically send this doc to your IT team’s Google Chat channel.

Outcome: Your flow doesn’t fail silently, users are notified and assisted without manual intervention, and error handling becomes part of your workflow logic.

Conclusion

Error handling in Zenphi is more than just preventing failures—it’s about building resilient, intelligent workflows that adapt when things go wrong. Whether you’re applying simple retries, notifying your team with global alerts, or designing advanced recovery logic using conditional branches and boolean checks, Zenphi gives you the tools to stay in control.

By combining systematic settings, manual intervention options, and smart automation, you can ensure your processes remain reliable, transparent, and efficient—even in the face of unexpected issues.