Build an exception table with item ID, source, failed step, error, completed effects, and next decision. Review whether the failure is retryable, needs corrected input, or requires inspection of an uncertain external action.
In this guide
What should the exception queue look like?
This training batch has three accounted-for items and no confirmed completed conversions. Missing output is not a valid empty document. After each repair, add the new attempt and result to the same item row; do not erase the original failure. A reviewer can then close each item as completed, still open, or deliberately canceled without losing track of the batch size.
| Item | Last confirmed step | Exception | Recovery action |
|---|---|---|---|
| PDF-A | Listed in manifest | Source file missing | Ask document owner for the source |
| PDF-B | File opened | Model download incomplete | Finish setup, then retry conversion only |
| PDF-C | Markdown already exists | Overwrite stopped | Inspect existing output before choosing a fresh destination |
Which repair does each failure need?
- Identify the item, input version, run attempt, and last confirmed completed step.
- Classify missing input, validation error, temporary service failure, processing defect, and uncertain external result separately.
- Check whether any downstream action already occurred and record its destination reference.
- Choose retry, corrected-input run, manual review, or cancellation with an explicit reason.
- Replay the smallest appropriate unit with duplicate protection and a new attempt record.
- Reconcile the manifest, successes, exceptions, and cancellations after recovery.
How should the host handle failed steps?
Activepieces documents step settings and run inspection that can support recovery decisions. Check the current behavior of the settings you choose: continuing after failure can be useful for collecting exceptions, but it can also allow later steps to operate on incomplete data.
Review timeout, file, retention, and other limits in your actual hosted or self-hosted setup. Keep important source and review records beyond an ephemeral run log when the business needs them. No default limit should be assumed to match every installation.
Keep the intended work visible even when output is missing
Create the batch manifest before processing. Give each input an item ID and expected output or action. This lets you compare intended items with successful outputs rather than discovering missing work through a customer's complaint.
The exception queue can be a table and review routine you build in your existing tools. It should not be described as a dedicated product feature unless your chosen software actually provides one. Preserve source references, relevant run details, and a reviewer while avoiding unnecessary sensitive content in logs.
Use a concrete exception record
item_id_and_source_version: [reference] expected_output_or_action: [state] attempt_id_and_time: [record] failed_step_and_error: [observed facts] last_confirmed_step: [state] external_effect_and_reference: [none confirmed / succeeded / uncertain] category: [input/validation/temporary/processing/uncertain] reviewer_and_next_action: [assign] replay_result: [new attempt + outcome] Keep missing output distinct from a valid empty result. Inspect uncertain side effects before retrying.
Close a batch by reconciling the work
A batch is accounted for when each intended item has a recorded successful, unresolved, or deliberately canceled outcome. Save the exceptions and their owners with the result. Use repeated failures to improve the input contract or the workflow rather than silently extending the retry loop.