Action outcomes and errors

A user confirms an application. The bot needs to change its state only while it is still new, then respond differently when it was changed, already changed, or no longer exists. Attach these responses directly to action outcomes instead of comparing a status string in another action.

An outcome route selects which reaction to run next. Once a route is selected, the current sequence ends and actions below it do not run.

The separate branch_value and branch_result actions have a different continuation rule. Outside a block, the parent reaction continues with its next actions after the selected reaction finishes normally. Inside a reusable block, that branching ends the block call. Account for this when placing the next message or calculation.

Example: confirm an application

For a sample run, create a requests collection with a text field named state and a record whose state is new. Enter that record's ID directly in the action. The JSON below shows the alternative where search or a button has already supplied the ID as ctx.selected_id.

1. Prepare reactions for successful update, conflict, missing record and technical error.
2. Add Update record if with the collection, record ID, expected state and new state.
3. In Outcome routes, select reactions for Updated (updated), Conflict (conflict), Record not found (not_found) and Technical error (error).
4. Put the successful confirmation message in the updated reaction.

Technical format; replace the route IDs with your own reaction IDs:

{
  "type":"record_update_if",
  "params":{
    "collection":"requests",
    "record_id":"{{ctx.selected_id}}",
    "expected":{"state":"new"},
    "values":{"state":"confirmed"},
    "save_to_ctx":"transition"
  },
  "outcomes":{
    "updated":"00000000-0000-4000-8000-000000000001",
    "conflict":"00000000-0000-4000-8000-000000000002",
    "not_found":"00000000-0000-4000-8000-000000000003",
    "error":"00000000-0000-4000-8000-000000000004"
  }
}

expected and values contain strings converted using the collection schema. If only the record's owner may change it, check ownership and state in the same operation. See conditional updates.

conflict means the record exists but its expected values did not match. It remains a distinct result even though the database call had no technical error. Current record values are not disclosed by a conflict.

Configure routes in the editor

On the Actions tab, open the action card and find Outcome routes. Select a reaction from the same project for each result. Supported actions inside a loop have these controls too.

The option to continue using the action's rules leaves that outcome without a separate route. It does not promise that every result continues: conflict and error rules are described below. To clear an existing selection, use Remove route beside the corresponding outcome.

If changing an action's type or settings makes existing routes unsupported, the editor retains them until you explicitly repair them. Choose appropriate reactions or remove unsupported routes. A save error can reveal the affected collapsed card.

Importing JSON with incompatible outcomes first opens a repair draft. Fix the routes and save it as a new reaction. The reaction identified by the source file's ID is not overwritten.

After saving, check target reactions and outcome labels on the graph. Its reaction-list view displays the same connections as text.

If an outcome targets the current reaction, duplicating it makes that outcome target the new copy. Links to other reactions keep their existing targets. The copy starts disabled; review its conditions and actions before enabling it.

Available outcomes

Conditional updates reject the generic success outcome. Choose updated so that a conflict cannot trigger successful confirmation.

A transaction's successful outcome is committed: all its operations were saved together. conflict stops the sequence, loop and block call even without a selected route or with outcomes: {}. A later success message does not run. See the last-seat practical lesson.

Control actions such as transitions, branches and loops use their own routing logic. Asynchronous steps and questions waiting for a reply do not automatically gain these outcomes. The editor offers only the options supported by the selected action.

New outcomes are not yet supported for payment creation, subscription creation/cancellation/update, or the built-in GetCourse, Google Sheets and Google Drive actions (payment_create, subscription_create, subscription_cancel, subscription_update, getcourse, gsheets, gdrive). Validation rejects nonempty outcomes on these actions. The actions remain available without this setting.

For HTTP requests, choose either these outcomes or the request's separate on_success / on_error targets. Mixing them is rejected to prevent two dispatches. Existing HTTP retries stay part of the request; error does not add automatic retries.

Continuing or ending a sequence

• A matching route runs its target reaction and ends the current sequence.
• Ordinary success or committed without a selected route may continue to the next action.
• An unhandled technical error fails the execution.
• When a conditional update has at least one route configured but no route for the actual updated, conflict or not_found result, the sequence stops. The trace identifies the missing matching route.

Without configured outcomes, existing reactions retain their previous behaviour. An empty outcomes: {} also means this setting is absent. An existing flow that conditionally updates a record and then branches on transition.status continues to work as before.

Inside a new reusable block, a conditional update additionally stops the call on conflict or not_found, even without outcomes on that inner action. This prevents the block from returning a successful calculation after a refused update. Configure a route on the inner action to provide your own response.

If an action inside a loop selects an outcome route, the loop and the remaining actions in the current reaction stop. The next iteration does not start after that transition.

Once a target reaction has been selected, an error in that reaction does not switch the original action's outcome to error. The route decision stays fixed, and the failure belongs to the selected reaction.

What success means

Each action defines its own success conditions. If a service returns a business status in its response body, check it separately with a value branch.

A message outcome does not confirm that the recipient read the message. Check delivery in the channel log. Outcomes also do not turn several separate record changes into a transaction.

When a task is retried, its route or stop decision is retained so execution does not continue after a previously selected transition. This does not promise exactly-once execution for every external service.

Checks with sample data

1. Confirm a new application and check updated.
2. Repeat confirmation and expect conflict, without success below it.
3. Use a missing ID and check not_found.
4. Configure only updated, then trigger a conflict and expect the sequence to stop.
5. In safe test mode, provide an external-step error and check error.

Related material: actions, conditional updates and branching, practical exercises.