Workflows

A workflow is the set of statuses a work item can be in and the transitions between them. Orbit edits workflows as drafts, previews the impact on existing work, and publishes them as immutable revisions.

Who can edit

Who edits a workflow depends on how the project is managed. This is chosen when the project is created.

Project	Who changes workflows, statuses, work types, screens and custom fields
Company-managed	Site administrators only. Project administrators get a refusal.
Team-managed	The project’s administrators. A team-managed project cannot use a shared workflow.

Members, roles, components, versions, boards, features, the notification scheme, automation rules and project details stay with project administrators in both kinds of project.

Statuses and categories

Every status belongs to a status category, and the done category marks finished work. Reports and boards use the category. A workflow uses a nonempty subset of the status catalog (backlog, to do, in progress, in review and done) and has an initial status. Without any custom workflow, a project uses the read-only built-in default workflow. A work type can have its own workflow that overrides the project default.

Transitions

A transition is a directed edge between two statuses with an ID, a name and a source that is a status or * (from any status). Explicit loop transitions (a status to itself) and parallel edges are supported. A workflow with no transitions denies all movement.

Each transition can define:

Conditions and permissions on who may run it.
Resolution behaviour: keep, clear or set the resolution, and whether one is required, with the allowed choices. If more than one transition applies to a status change, Orbit asks which one.
Validators (required fields): up to three of assignee, description and due date must be filled in. If one is missing the dialog names it and offers to edit the work item. A failed bulk transition leaves all the participating items unchanged.
Transition screens that ask for fields during the transition.
Post-actions that run deterministically after the transition.
Approval: see below.

Moving a work item through a transition checks the current graph, the project binding and the person’s fresh rights at the moment of the write.

Drafts, warnings and revisions

Open the workflow editor and make your changes. They are saved as a draft: shared project configuration that is separate from the workflow in use. The built-in workflow cannot be drafted.
The editor shows warnings before you publish: unreachable states, invalid transitions and missing required values.
Publishing creates the next immutable revision. A history lists every published revision with when and by whom. You can draw any revision and see how it differs from the current one.

Only the current project or site administrators can change a draft, preview and publish. Anyone who can read the project can read drafts and revisions.

Impact preview and publication

If a change removes a status that work items are in, Orbit does not apply it silently. A direct edit is refused with a conflict that lists the affected work items. Use the impact preview instead: it shows which work items are affected and asks you to build a status migration plan, that is, where work in each removed status goes. Publication applies the plan and the new revision together. Concurrent edits are protected: if the draft or the bindings changed since you started, you review again.

Shared workflows

A site administrator can share a project workflow under a name. Other company-managed projects then follow it. Following projects get a read-only linked copy with their own revisions. An edit to the shared workflow is synced to every follower, and a follower whose statuses would orphan work gets a synced draft and waits for a publication review. A follower can be detached, which turns it into the project’s own copy.

Editing a shared workflow needs shared-configuration authority, that is, a site administrator. Shared workflows cannot use transition screens or project custom fields, and a status made inside a project cannot be shared.

Approval steps

A transition can require approval before it runs.

Approvers come from a project role, groups (1 to 20) or a user field.
A quorum of 1 to 20 approvals is needed. It defaults to 1.
Delegation can be allowed. A delegate inherits the slot and cannot delegate again.
A rejection route is another transition of the same workflow that leaves the same status.

The requester asks for approval, and Orbit snapshots the eligible approvers (active project members who can read the item, not the requester). While a request is pending the work item cannot move. Each approver approves or rejects once. Reaching the quorum runs the transition for the requester, and one rejection runs the rejection route. Every step is audited and notifies the approvers or the requester. You can preview whether a request can be made without creating it.

Status

All of the above is built.