Errors and retries

Understand before retrying

Permission refusal, invalid input and temporary unavailability require different responses. Progress identifies the affected operation and correction needed. Recovering an uncertain technical response retains the same operation identity. A new business attempt creates its own work and Task; it is not a replay of the previous attempt.

Situation	Expected action	Effect to verify
Invalid input	Correct the named Field or parameter	Preserve other values
Permission refusal	Review access	Do not bypass checks
Unavailable connection	Restore connection or profile	Resume the authorized step
Uncertain response	Inspect receipt and result	Avoid duplication
Result needs review	Request targeted correction	Preserve approved parts

Example

Quote finalization was accepted but the interface lost the response. Before running again, progress retrieves the operation and result. The same request must not create a second quote.

Define recovery policy

Steps have bounds and explicit policies. Permanent failures need correction; transient failures may admit bounded retries. Human approvals are not replayed like technical requests.

A permission refusal, stale source or rejected approval does not authorize automatic retries. An uncertain external outcome requires the connection’s idempotency guarantee or reconciliation before another effect is requested. A Surface receipt alone does not guarantee that an external provider executes exactly once.

When resuming work suspended for access checks, an acknowledged or retained confirmation does not mean that the work is complete. Progress distinguishes a retained resume request, unknown delivery and access still in transition; in the last case, it states whether your confirmation was recorded. Read the current status without starting another execution. The receipt for an earlier confirmation describes that confirmation, not necessarily the current state of the work. If delivery remains unknown, retain the same request instead of creating another resume request.

Cancel without losing evidence

Cancellation closes new launches and preserves completed results, decisions, work and consumed budgets. Requests to cancel already launched Tasks remain visible; they do not prove that a provider has stopped or that its effects have been undone. A cancellation request and a confirmed stop are different facts. Any business compensation is a separate, authorized Action.

When requesting help, share useful diagnostics from progress without secrets or unnecessary private information. See Troubleshooting for the diagnostic journey.

Applied examples : Resume with explicit limits

Retries are bounded by the step and the Flow budget.

Configuration

Fragment placed in flowBlueprints[].composition.steps[]. Properties and accepted values.

{
  "key": "prepare",
  "kind": "task",
  "workNodeKey": "prepare",
  "actionKey": "prepare",
  "inputs": {},
  "outputs": [
    {
      "key": "proposal",
      "type": "result-reference",
      "provenance": "canonical",
      "minimum": 1,
      "maximum": 1,
      "result": "reference"
    }
  ],
  "reservedCostUnits": 1,
  "maximumAttempts": 3
}

Variation and connection

Fragment placed in flowBlueprints[].composition.budgets. Properties and accepted values.

{
  "maximumDepth": 2,
  "maximumOccurrences": 20,
  "maximumConcurrency": 2,
  "maximumIterations": 3,
  "maximumDurationMilliseconds": 86400000,
  "maximumCostUnits": 100,
  "maximumStateBytes": 32000
}

UI layout example

The illustrative layout below places this configuration in the Clients/Quotes app. Insert each fragment at the stated location, with Field, Query and Action references matching the Model declarations.

1. Target object
2. Proposed change
3. Checks
4. Confirm

SurfaceClients / North StudioExample

Errors and retriesResume with explicit limits

Clients

NS

North StudioQuote S-1042

Needs review

Proposed change

Retries are bounded by the step and the Flow budget.

Data and references

Client · Need · Pricing

BackReview then confirm