Error Handling

Error handling decides what Automation Hub should do when a step cannot finish successfully.

Not every error should stop the whole automation. Some steps are critical, like charging a payment or updating a database. Other steps are helpful but not essential, like sending a status email. Error handling lets you choose the right response for each step.

Error handling is configured per-step in the step's settings panel. Each step in your automation can have its own error handling strategy, so you can fine-tune the behavior based on how important that step is.

The Basic Idea

Something Fails

A step cannot complete because of missing data, timeout, permissions, or another issue

Automation Hub Checks

The step setting tells the job whether to stop, continue, or continue with a warning

Job Responds

The job follows the rule and records what happened for review

Simple: decide in advance which failures are serious and which ones the job can work around.

Three Choices

Stop the Job (STOP_WORKFLOW)

warning

STOP_WORKFLOW is the default error handling strategy for all steps. If you do not explicitly configure error handling, a failed step will always stop the entire job — make sure this is the intended behavior before relying on defaults.

This is the default strategy. Choose this when the failed step is required for the rest of the job.

Step Fails

A critical step cannot complete

Job Stops

Remaining steps do not run

Job Marked Failed

The entire job status is set to FAILED and the reason is recorded

Use this for:

• Reading required customer data
• Validating payment details
• Updating important records
• Any step where later steps depend on the result

Continue Anyway (CONTINUE)

Choose this when the failed step is useful, but the job can still succeed without it.

Step Fails

A non-critical step has an issue

Step Marked Completed

The step is marked COMPLETED despite the error

Job Continues

The next step runs as if nothing happened

Use this for:

• Sending a courtesy notification
• Writing a non-critical audit note
• Updating an optional dashboard
• Any step that should not block the main work

Continue and Flag the Problem (CONTINUE_WITH_ERROR_OUTPUT)

tip

Use CONTINUE_WITH_ERROR_OUTPUT when a later step needs to react differently based on whether the current step succeeded — for example, routing to a fallback system or creating an alert ticket.

Choose this when the job should continue, but later steps should know that something went wrong.

Step Fails

A step has a problem that later steps may need to handle

Step Marked Failed

The step is marked FAILED, but the job keeps going

Downstream Steps React

Later steps can check the error and take a different path using conditional branching

Use this for:

• Calling an external system that may be temporarily unavailable
• Trying one data source before falling back to another
• Logging a monitoring event after a warning
• Any step where the job should adapt instead of simply stopping

Which Choice Should You Use?

If the failed step is...	Choose	Example
Required for the job to make sense	Stop the Job (STOP_WORKFLOW)	Customer lookup fails before sending customer email
Helpful but not essential	Continue Anyway (CONTINUE)	Status email fails after the main work is done
Something later steps should react to	Continue and Flag (CONTINUE_WITH_ERROR_OUTPUT)	API call fails, then a later step creates a support ticket
Risky to repeat or ignore	Stop the Job (STOP_WORKFLOW)	Payment, database update, or approval validation fails
Usually affected by temporary issues	Retry first, then follow the error rule	Network call, file download, external API request

Common Error Types

Automation Hub classifies every error into one of these types so you can quickly understand what went wrong.

Error type	Internal name	Plain-English meaning	What to check first
Connection error	CONNECTION	Automation Hub could not reach another system	Is the system online? Are network settings correct?
Timeout error	TIMEOUT	A step took too long to respond	Is the external system slow? Is the timeout too short?
Not found error	NOT_FOUND	The item does not exist or the ID is wrong	Is the record, file, ticket, or path correct?
Permission error	PERMISSION	The job is not allowed to do the action	Does the connection have the right access?
Data error	DATA	The step received missing or unexpected data	Did the previous step return the expected information?
Configuration error	CONFIGURATION	The step or connection is set up incorrectly	Are all required fields filled in? Are settings valid?

Automation Hub also automatically detects transient errors -- temporary problems like timeouts, connection resets, and TLS handshake failures. When a transient error is detected, it is classified as retryable, which means the retry system can attempt the step again automatically.

What You See When Something Fails

When a job or step fails, Automation Hub records detailed information that helps you understand what happened.

Information	Internal field	Why it helps
Whether an error occurred	exceptionOccurred	Quick yes/no check for any failure
Error type	errorType	Groups similar problems together (CONNECTION, TIMEOUT, etc.)
Error message	errorMessage	Explains what went wrong in plain language where possible
Stack trace	stackTrace	Technical details for developers to diagnose complex issues
Error details	errorDetails	Additional context about the failure
Time of failure	errorTimestamp	Helps match the issue to system changes or outages

Start with the error type and error message. Those two usually explain the next action.

Practical Examples

Customer Notification

Read Customer

STOP_WORKFLOW: stop if customer data is missing

Send Email

CONTINUE: continue if the email service has a temporary issue

Log Summary

CONTINUE: save what happened for review

Why: You cannot send a correct email without customer data, but the main customer lookup should not be considered useless just because a notification failed.

Payment Process

Validate Payment

STOP_WORKFLOW: stop if validation fails

Create Receipt

Runs only after payment is valid

Send Confirmation

CONTINUE: continue if email delivery fails

Why: Payment validation is too important to ignore. Confirmation email is useful, but it can be retried or handled separately.

External System Check

Call External API

CONTINUE_WITH_ERROR_OUTPUT: record the failure for downstream steps

Check Result

Use conditional branching to see whether the API call worked

Create Alert

If it failed, notify the right team

Why: The job can still do useful work by creating an alert, even if the external system did not respond. The conditional branching (using falseLinks in the automation's step graph) lets the job take a different path based on the failure.

Retry Before Giving Up

Some failures are temporary. Automation Hub can retry a failed step before applying the final error handling rule.

Use retries for:

• Temporary network issues
• Busy external systems
• Rate limits
• File locks
• Slow APIs

Avoid automatic retries for:

• Payments or actions that could happen twice
• Bad credentials
• Missing required data
• Steps where repeating the action could create duplicate records

If all retries fail, the step follows its error handling choice: stop, continue, or continue and flag.

A Simple Decision Guide

Ask these questions when setting up a step:

1. Can the job continue safely without this step? If no, use Stop the Job (STOP_WORKFLOW).
2. Is this failure usually temporary? If yes, add retries.
3. Should someone know about this failure? If yes, use Continue and Flag the Problem (CONTINUE_WITH_ERROR_OUTPUT) or send an alert.
4. Could repeating this step cause duplicate work? If yes, be careful with retries.
5. Will later steps need this step's output? If yes, use Stop the Job (STOP_WORKFLOW) when it fails.

Tips for Better Error Handling

Mark critical steps clearly

• Customer lookup, payment validation, approvals, and database updates often need to stop the job

Do not let small failures block important work

• A failed notification should not always cancel a successful process

Use retries for temporary problems

• Network calls and external systems often recover after a short wait

Review repeated failures

• If the same step fails often, fix the root cause instead of only rerunning the job

Test failure cases

• Try missing data, wrong credentials, and slow systems before relying on the automation in production