Skip to main content

Workflows: run, schedule, approve

Start a run by hand or on a schedule, follow it, act on the steps that wait for you, and read why a run failed or stopped. The workflow needs an active version; Run Now and Run on Schedule are also disabled while the licence is on hold (Banners you may see). If the version declares an S3 prefix parameter, its AWS connector must be stamped Last verified (AWS connector).

Steps​

Run now​

  1. Open the workflow and click Run Now. Without parameters the run starts at once and you land on the run page. With parameters, Run with parameters opens ("name takes N parameters (k required). The run executes in the background."); an S3 prefix field expects folder/subfolder/ when the parameter has a fixed bucket, or s3://bucket/folder/ otherwise. Click Start run.
  1. Or, on Workflow Runs, click Start a Run: pick the workflow (Select a workflow…; workflows with an active version, read name (vN)), fill its parameters, optionally type an Optional input for the first agent ("Anything you want the first agent to know…"), then Start run.

Run on a schedule​

  1. Click Run on Schedule ("Times are interpreted as UTC unless you name a timezone."). Describe the cadence under Schedule (natural language), for example "every weekday at 9am UK time", and click Generate cron: EventBridge expression fills in (for example cron(0 9 ? * MON-FRI *)) with a default Schedule name and any translation notes. Edit either, then Create schedule; a toast confirms the expression.

The Schedules table lists Name, Schedule (expression and plain-English reading), Status (Enabled or Disabled) and Last Triggered, with Enable / Disable and Delete (confirmed in Delete Schedule). Each schedule is an Amazon EventBridge rule: when it fires, the active version at that moment runs as the schedule's creator with Trigger Schedule. Accepted: six-field cron(...) or rate(n unit). If a run is still going, the workflow's If a run is already going setting (Skip, Queue or Parallel) decides; with Queue, at most 10 runs wait and start oldest first. A firing that cannot start within 15 minutes of its time, because the deployment was paused or Studio was down, is skipped, and the next firing runs on time; Last Triggered does not change for a skipped firing.

Read the runs list and a run​

  1. The Runs section of a workflow's page (or its URL plus /runs) lists that workflow's runs. Workflow Runs at /workflows/runs lists every run in the deployment: Run, Workflow, Status (Queued, Starting, Running, Needs you, Completed, Failed, Stopped), Trigger (Run now, Schedule or API), Version, Started, Duration, Stages, Deliverables, Needs you and Summary. Search runs by ID or workflow name…, then click a row.

  1. The run page has four areas:

    AreaWhat it holds
    HeaderWorkflow, version, the run id's first eight characters, the Trigger chip (with the caller's reference on API runs), start, duration, the time-limit chip and the status pill; Stop (while going), Re-run (once finished; same parameters), Open workflow and More (Copy link, Download run: a zip of the run's folder).
    Board (left half)One card per step with its status and a Governor badge where it commented; a card opens Thread, Tool Calls, Governor and Evidence (Chat: the board, Governor).
    Summary (right pane)The outcome strip with the PII chip; a Needs you block per waiting step; Run inputs; PII redaction; Deliverables (every file a step wrote under outputs/, with a chip to the step that wrote it); Run narrative; Result with Open result.json; Stages, with an Outputs redacted shield where redaction ran; AMPG changes; a Failed or Stopped block.
    Files, Preview, AMPG (right pane)As in Chat (Chat: files, previews and approvals); Files offers This run, Workflow root and All my files, and a governed deployment adds Everyone's files.

    The page refreshes every 15 seconds while visible. While a run is Queued its header shows only the wait ("Waiting for the current run to finish.") and Stop; the workflow name, version and run id appear once it starts. After you approve a waiting step, the pill can keep reading Needs you and the duration can stand still until that step finishes; Stages in the Summary shows where the run is.

Approve, send back or stop​

  1. A step waits when its Task has Hold the result for my review or Wait for my go-ahead before it runs on, when it is a Handoff, when the agent's coder wants to run a flagged command, or when the agent wants to use a connector tool that asks before running; the card reads Awaiting review, Awaiting go-ahead, Wants to run a command or Waiting for your approval and the pill Needs you. Act in any of three places with the same buttons: on the card (Accept, Approve & run, Allow this command or Allow; Send back opens a one-line note, Send returns it; A on a selected card approves); in the Summary's Needs you block (Cancel only closes the note); or in the Inbox. Approvals raised by API-started runs appear in the Inbox for everyone assigned, and whoever acts is recorded on the run.
  • Approve (Accept, Approve & run, Allow this command, Allow): the run continues; the page shows Resuming….
  • Deny on a connector tool: that one call is refused and the agent carries on without it, told why in your note. A connector tool call nobody decides on within 30 minutes is not run.
  • Send back with a note: the held step redoes its work with your note; on a go-ahead, the note is applied when the step runs; on a Handoff, the step before it runs again.
  • Stop (the Inbox card or the run page's button): cancelled at that step; everything produced so far stays in Files. The pill reads Stopped and the block says who stopped the run and when.

What you should see​

A started run: Starting… then Running, cards turning Done, files under Deliverables and Files. A finished run: Completed, a Run narrative, Open result.json, and the run under Done in the Inbox. A run whose knowledge-graph publish was still building after 60 minutes ends Completed · 1 warning, not Failed: the step's card carries the warning ("It will become active on its own; re-run this step later to adopt it, or check the AMPG's versions page."). A schedule: an Enabled row whose Last Triggered fills after the first firing. A Failed run: a Failed block naming the step and reason, or, before any step ran, one of "The run inputs could not be copied before the first step.", "The run reached its time limit and was stopped.", "The run never reached the runtime." or "The runtime has no record of this run." With redaction on, the strip reads "PII redacted · N values · k categories" (or "PII redaction · completing…") and PII redaction lists each stage (PII redaction).

Notes​

  • A time limit counts from the moment the run is queued and never pauses, so waiting for your approval counts; at the limit the run is stopped and marked failed. Runs continue after you close the tab; only Stop ends one.
  • A schedule's only editable field is Enabled / Disabled; to change the cadence, delete it and create a new one.
  • Times are not labelled with a time zone. The runs lists' Started column, the run header and Inbox cards show your browser's local time; Version History shows Activated as a UTC timestamp. A workflow page's Runs section is not in start-time order; read the Started column.
  • An error under a parameter field: the value failed its rule; other refusals appear above the form word for word. "Failed to translate schedule" or "Failed to create schedule": retry, or type the expression. "Could not load the run.", "Stop did not go through.", "Re-run did not start.", "Download failed.": reload and retry. A step Failed: the reason is under its title, the trace in Thread and Tool Calls. A step Skipped: an untaken Conditional branch; its line names the branch that was taken instead, or why the step did not run.