Salesforce Docs Portal

Manual Queues for Fallout Handling

As a Fulfillment Designer, you can associate an error queue with an orchestration item when configuring orchestration items.

The following types of orchestration items can have associated error queues:

  • Callouts

  • Auto Tasks

  • Push Events

Orchestration items that are manual tasks do not have specific failure queues associated with them. Instead, when a failure occurs, the task remains in the manual queue but its state is set to Failed.

Whenever an error occurs on the orchestration item, an entry is placed in the associated error queue for manual handling. If an error queue has not been defined, you must resolve the error in the orchestration item view. At runtime, you can navigate to the error queues to select tasks on which to work by clicking the Assign to me button. This may involve editing order data, which is not recommended, updating information in external fulfillment systems, and retrying the task, or completing the task without a retry.

Note
Note

It is not recommended to change order data after fulfillment has started.

When using the DefaultSystemInterface implementation for callouts, the errors are identified by interpreting the HTTP status codes from the response provided by the fulfillment system. The implementation maps codes to one of three statuses:

  • Failed: This is a system-recoverable error.

  • Fatally Failed: This is a manually-recoverable error.

  • Completed

The following list shows the successful and recoverable HTTP error codes in the DefaultSystemInterface implementation. If a code is received that's not in this list, the item is moved to Fatally Failed (and must be manually recovered):

  • If the acknowledgment is one of the expected success codes (200, 201, 202, 203, 204, 205, 206, 302, or 30): The callout remains in the Running state.

  • If the acknowledgment is one of the expected error codes (408, 426, 500, 502, 503, 504, 440, 444, 520, 522, 523, 524, or 525): The callout moves to the Failed state, and is retried according to the retry policy.

    For information about retry policies, see: Set Up Retry Policies for Failed Callouts

  • If the acknowledgment is any unexpected code: The callout moves to the Fatally Failed state and isn't retried again, regardless of the retry policy.