Managing Fallouts

A fallout is an execution that failed and now needs handling. Engage records every one, but what happens next is up to configuration: a fallout definition matches the failure to an error definition and a retry policy, the policy retries automatically, and when the retries run out the fallout waits for an operator. This section covers the configuration; the screens where operators work the queue are under Monitoring.

The three objects, and how they fit

Object	What it holds	Where it is set
Error definition	A code, a name, a category, and a default severity for one kind of failure	Settings > Error Definitions
Retry configuration	How many times to retry, how long to wait, and when retries are allowed to run	Settings > Retry Config
Fallout definition	Which error, in which integration and step, is handled by which retry configuration	Settings > Fallout Definition

A fallout definition points at one error definition and one retry configuration, so the first two exist before the third. Both can also be created inline from the fallout definition form, which is the usual order when defining a fallout from a live failure.

Two scopes

Each object exists at organisation scope, under Settings, or at application scope, under an application's Configuration > Fallouts tab. An application-scoped fallout definition names a workflow and a step; an organisation-scoped one matches on error code alone and applies everywhere. Application-level lists show organisation-level entries too while the Organization Scope switch is on, which it is by default.

Configure fallout handling

Fallout definitions

Match a failure to an error and a retry policy, at application or organisation scope.

Define a fallout →

Error definitions

Name and classify the errors Engage should recognise.

Define an error →

Retry configuration

Fixed-interval or exponential retry policies, with active hours and eligible errors.

Create a policy →

Retry rules

How automatic and manual retries resolve, and what an operator can do with an exhausted fallout.

Understand retries →

Where to start

If you are setting Engage up for a new application, read Retry rules first to see how the pieces resolve at run time, then create a retry configuration and define fallouts against it. If you are looking at a failure right now, open it under Global Fallout and select Define Fallout there; the form arrives pre-filled with the failing service, step, and error.