Error handling

Workflow executions can fail for several reasons, including API errors, network issues, and invalid data. When failures occur silently, they can lead to incorrect customer states, disrupt billing or entitlement flows or delay product access or provisioning.

To make your workflows production-safe, we strongly recommend centralizing error handling using two mechanisms:

• A dedicated Error Workflow
• The Stop And Error node for conditional failure control

​

Setting up an error handler workflow

Use a dedicated workflow to act as a centralized error handler. This lets you respond to workflow failures by sending alerts (e.g. Slack/email), writing to logs, or notifying internal systems.

​

Create an error handler workflow

1. Go to Workflows > New Workflow.
2. Add the Error Trigger node as the first step.

3. Add any alerting or logging actions (e.g. send Slack message, send email).
4. Name the workflow something like “Error Handler”.
5. Click Back to canvas to save.

You can reuse the same error workflow across multiple workflows.

​

Link the error handler to your main workflow

Instead of manually routing errors via nodes, you can automatically run an error handler workflow whenever a failure occurs.

To set this up:

1. Open the main workflow that should be monitored for failures.
2. Click the Options (⋮) menu in the top-right corner.

3. Select Settings.
4. In the Error workflow field, choose the Error Handler workflow you created earlier.

5. Click Save.

This method ensures that any uncaught execution failure (e.g. a node error, network failure) will automatically trigger the error workflow — without needing to manually call it using an Execute Workflow node.

​

Simulating failures with the Stop And Error node

The Stop And Error node is a utility to intentionally fail a workflow under custom conditions — which can be useful for:

• Triggering the error handler in response to business rules (e.g., invalid subscription state)
• Testing how workflows behave when something goes wrong
• Preventing downstream steps from executing when a critical condition fails

To set up the Stop And Error node:

1. Open your workflow.
2. At the appropriate point in the logic (or as a fallback branch), insert a Stop And Error node to force an execution failure under certain conditions.
3. In the Parameters tab:
   1. Choose between Error Message or Error Object.
   2. For Error Message, enter a plain-text message.
   3. For Error Object, provide a full JSON structure.
4. In the Settings tab, define additional logic if needed.
5. Click Back to canvas to save.

​

Error trigger schema

When a workflow fails and your Error Workflow is triggered, it receives a payload like this:

[
	{
		"execution": {
			"id": "231",
			"url": "https://example.com/execution/231",
			"retryOf": "34",
			"error": {
				"message": "Example Error Message",
				"stack": "Stacktrace"
			},
			"lastNodeExecuted": "Node With Error",
			"mode": "manual"
		},
		"workflow": {
			"id": "1",
			"name": "Example Workflow"
		}
	}
]

Notes:

• retryOf is only present on retry attempts
• lastNodeExecuted helps pinpoint the failing step

If failure occurs in the trigger node of a workflow (e.g., during activation), the error data will look different:

{
  "trigger": {
    "error": {
      "context": {},
      "name": "WorkflowActivationError",
      "cause": {
        "message": "",
        "stack": ""
      },
      "timestamp": 1654609328787,
      "message": "",
      "node": {
        . . . 
      }
    },
    "mode": "trigger"
  },
  "workflow": {
    "id": "",
    "name": ""
  }
}

This is useful for catching misconfigured integrations or credential errors.

​

Best Practices for Stigg Workflows

• Use one centralized error handler workflow across all critical automations
• Send alerts to Slack/email so teams are immediately aware of failures
• Include user context (e.g., customerId, subscriptionId) in Stop And Error nodes for traceability
• Avoid leaving workflows in partially-completed states by detecting edge cases early and halting gracefully