Execution and attempts

Execution starts from an eligible reviewed bot definition. The execution workflow claims the run once, then records an observed bot result, an execution attempt, a durable operation and a numbered step. The attempt carries its operation key and attempt number, start and finish dates, provider reference, failure reason and status. That detail helps the Automation Operator distinguish work still running from a failed or uncertain call.

The observed bot result is a separate record. It can carry a sequence, observation date, quantity, amount, source reference and outcome. The outcome values Pending, Accepted and Rejected describe the observed result; they are not substitutes for the operation status or the review decision. The definition holds its current status and result fields, including start and completion dates and an exception code when applicable.

• Claim. An operation key identifies the execution so repeated requests do not become separate claims of the same work.
• Attempt. The attempt log shows each provider interaction and its final or uncertain status.
• Result. The observed bot result records what the run reported against its parent definition.

Define when an approved and scheduled definition becomes eligible to run. Agree which system supplies the provider reference and how an unknown attempt is reconciled before another try. Define who may inspect a failure reason and who owns an exception after the provider responds. Keep a shared rule for preserving the operation key when retrying the same logical action.

For example, the approved extract bot starts and the provider response is delayed. The operator sees an attempt with an uncertain status and a durable operation whose result still needs reconciliation. The operator checks the provider reference and numbered step before requesting another action. Once a confirmed receipt arrives, the same logical execution can be completed without treating the delayed response as a fresh successful run.

Choose an approved scheduled definition. Trace its operation key from the durable operation to the attempt and the numbered step. Check that the observed bot result belongs to the same parent. Rehearse an uncertain provider response: the team should find the previous claim and its evidence before allowing another attempt. Confirm that an attempt marked Succeeded does not by itself stand in for a confirmed external receipt.

• Execution attempts requiring attention — Failed and uncertain attempts with provider and failure context.
• Observed bot outcomes — Results grouped by their recorded outcome.
• Durable operations to reconcile — Operations whose result needs human investigation.

See Execute and verify a run and Resolve an exception.