TestOrchestrator

Project Assignment

A workflow state can be offered by every project in the workspace, or only by the projects you choose. That is set in the Projects panel of the state editor.

The two modes

All projects
Every project offers the state, including ones created later. This is what you want for the states your whole workspace shares.
Selected projects
A project picker appears and only the projects in it offer the state — “Only these projects offer it.” Projects created afterwards are not added for you. At least one project must be chosen; leaving it empty blocks the save with “Choose at least one project, or this state appears nowhere.”

The row’s own description spells out the cost of narrowing: “Which projects offer this state. Narrowing it means this state can no longer be made the default.”

The default state is locked to all projects

A default state must apply to all projects. On the default, the Projects panel is read-only and says so in place. On any other state, narrowing the scope is allowed — but Set as default in the row menu then greys out with the reason The default state must apply to all projects. Widen the scope back to all projects and it becomes available again.

Reading the Projects column

The state list shows each state’s scope in its Projects column:

  • All — every project offers it.
  • A number — how many projects offer it.
  • None, drawn as a warning — the state is scoped to specific projects and none are chosen. Hovering it says “Not assigned to any project, so it appears nowhere.”

A state with no projects is invisible. It stays in the admin list, and it will not appear in any picker anywhere until you assign at least one project. The count only ever counts live projects, so a state attached only to deleted projects reads None too — which is the truth about where it shows up.

What a project actually offers

A state reaches a picker only if it is enabled and in scope for that project. Disabling a state removes it from every project’s picker without changing its assignment, and re-enabling brings it back to exactly the projects it was assigned to.

Changing the assignment

Switch between the two modes at any time by editing the state. Going from selected projects to all projects makes it available everywhere immediately. Going the other way removes it from every project until you pick at least one.

Changing scope does not move anything: items already in the state keep it, even in a project that no longer offers it.

Typical patterns

  • Shared core states — keep Draft, In review and Approved on all projects so every team reads the same vocabulary. The default has to be one of these anyway.
  • Team-specific states — scope something like Pending sign-off or Blocked by QA to the projects that actually use it, and every other project’s picker stays short.