You pressed Request run: what does Ground Control check, and where do you see it?

Back to all essays→

My view is that a run request should answer with a reason you can see on the screen you are using. You published a workflow in Workflow Studio, you pressed Request run, and the Workflows list shows no new run. Here is what Ground Control checks, where each answer appears today, and where the path still asks too much of you.

Start with the Workflows list. When a run of an active workflow is still going, the Last run column shows its start time and status and links to it. When there is no such run, the column says "No runs". If a run is already going, look there before you request another.

When live execution admission is closed for the workflow, the row carries the causes, and only then. There are two. The first, no-live-workflow-target, says no live run target exists for the workflow yet. The second, no-package-type-binding, says no package type is bound to the workflow. An open row serves no cause at all. An archived workflow with a binding still serves no-live-workflow-target, because the causes follow whether the row can run live, not only whether a binding exists.

Here the path asks more of you than it should. The Workflows list receives those causes but does not show them; it shows only the Last run column. You see a cause only at the Request run control. When the cause is the missing binding, that control says "No package type is bound for the run. Bind one." When it can, "Bind one" links to the place where you bind it. When the only cause is no-live-workflow-target, the control falls back to a general sentence: "Live execution admission is closed for this workflow. The registry did not provide the closed-gate cause, so Web has no action to clear it." In fact the row did send a cause. In the compact Studio header, the reason is in the button's tooltip and for screen readers, not on the screen.

Next, deployment history. An empty history used to be ambiguous. Now a workflow that the Workflows list serves to you, but that has no deployment yet, answers with an empty list. That is an undeployed draft. Any other id with no deployment you can read answers 404. This is the shape of the error body that a test checks, with the id replaced:

{
  "error": {
    "code": "object_not_found",
    "message": "workflow was not found",
    "object_type": "workflow",
    "object_id": "wf_example",
    "details": {
      "object_type": "workflow",
      "object_id": "wf_example"
    }
  }
}

The same 404 answers for an id that does not exist and for a workflow you are not allowed to read. A 404 here does not tell you which of the two is true. My view is that this is the right default for privacy, but it means a wrong id and a missing grant look the same to you and to your agent. If the Workflows list shows the workflow and its history still 404s, check the id first. If the list does not show it, ask who owns it.

Then the work package that your run serves. A package can now complete when it has no run that is still going. It does not need a run at all. It still needs no active hold, and the completion request still needs evidence references. A package with a run still going answers 409 runs_not_terminal with the message "work package completion is blocked by non-terminal runs". An active hold is a different 409, held. So "blocked" has two meanings, and the code tells you which one. The message does not say which run is still going.

Last, what you build. The Studio Add dialog now offers only the current choices, such as Agent work, Human approval, Router and Manual task. Retired step families such as Loop / retry and Checkpoint are not in the list, and a search for one gets the ordinary "No results" message. A saved workflow that already uses one keeps the step and its schema. Ground Control does not delete it. It still cannot run, and the refusal says so: "This node family was removed from new workflows. Its schema remains for saved workflows; it cannot execute." Event wait is also absent from the dialog, and it cannot run because no signal route exists yet.

What to check after you press Request run

• Look at the Last run column first. A run that is already going may be the run you wanted.
• If no run starts, read the reason at the Request run control, not the list. Hover over the button if the header is compact.
• If the reason is a missing package type, bind one, then request the run again.
• Read an empty deployment history as "listed, never deployed", and a 404 as "wrong id or no access".
• Read 409 runs_not_terminal as "a run is still going" and 409 held as "a hold is active".
• Replace a retired step in a saved workflow before you expect that workflow to run.

The agent guide explains the work and permission model. The quickstart covers connection and first steps. Read both before you let an agent request runs for you.