Error Handling

Error handling is not a special action - it is built into every step. Any step can hit an unexpected runtime failure, and metamorphOS lets you decide, per step, what should happen when it does.

Every step can be error-handled

From any step you can connect an error path to one or more follow-up steps. That path runs when the step errors at runtime, and when the person or agent holding the step’s task reports it as not completable. How to add the path in the builder is on Error Handling (Builder).

This is independent of a step’s own outcomes. A Conditional Branching step routes success or failure as part of its normal logic; an error path is the additional route taken when the step itself fails unexpectedly. Steps that have no logical branch of their own - like Push to Array

• can still be error-handled the same way.

Handled vs. unhandled

• Handled - you connected an error path. When the step errors, the process continues down that path. The reason for the failure is written to a text variable first (Fehlermeldung by default, or one you choose on the step), so the steps on the error path can read it.
• Unhandled - no error path is connected. The step’s error stops that branch of the instance, and the failure surfaces in the Monitor.

Because the choice is per step, you decide where robustness matters and where a hard stop is the right behavior.

What to do on an error path

An error path is just more process. Common patterns:

• Notify - alert a person or channel that something failed.
• Clean up - undo or compensate partial work.
• Fall back - try an alternative route or a default value.
• Escalate - hand off to a human task for manual resolution.
• Retry - loop back and attempt the step again.

Where errors show up

• The instance view marks the failed step and shows the reason; the Monitor lists failed instances across the workspace.
• Steps that can produce diagnostics expose them as outputs - for example, Run Script writes an Error Message and Logs you can route and inspect.

Best practices

• Add error paths to the steps that realistically fail - external calls, scripts, document generation - not to every trivial step.
• Keep a clear catch path that makes failures visible to someone.
• Don’t swallow errors silently; route them somewhere a person will see.

Related

• Error Handling (Builder) - adding an error path and choosing where the reason is written.
• Task Exceptions - a task reported as not completable takes the same error path.
• Monitor - find and inspect failed instances.
• Branching and Merging - how outcomes route to successor steps.
• Run Script - capture an error message and logs to drive an error path.