A workflow is a set of statuses and the transitions allowed between them. An issue always stands in one status of its type's workflow, and it can only reach the next one along a transition that exists.
A status and its category
A status has a name, which users read, and a category, which is how the product knows what the status means. There are three:
| Category | What it means |
|---|---|
TODO | not started |
IN_PROGRESS | under way |
DONE | finished |
The name belongs to the company. "In progress", "In review" and "With the client" are all IN_PROGRESS. The category exists for the places where the product has to reason about statuses it has never seen: boards lay their columns out by category, and in QQL the statusCategory field answers "what is still open" whatever a company called its own statuses.
Statuses belong to the company rather than to one workflow. The same "In progress" is reused across processes, and renaming it renames it everywhere at once.
Transitions
A transition is a named arrow from one status to another. Its name is what a user reads on the button.
Checked when the process is saved:
- a transition has to change the status; an arrow from a status back to itself is refused;
- two transitions with the same name between the same pair of statuses are refused;
- every status must be reachable from the initial one. A status no chain of transitions can arrive at will not save.
The initial status is chosen explicitly: every new issue on this process is born in it.
Draft and publication
Editing happens in the builder and touches no live issue until the draft is published. Publication is one action that validates the whole process and applies it.
It takes the right to edit workflows, and the version you were editing. If somebody else published while you were working, your publication is refused as stale rather than written over theirs.
Revisions
Every publication is kept as a revision: a complete snapshot of the process at that moment, with an author and a time. Revisions are read-only.
A revision stores the statuses and transitions themselves, not references to the current ones, so it stays readable even after a status has been renamed.
Restoring an earlier revision
You can go back, and it works like this:
- open the revision you want and load it into the builder as a draft;
- the builder tells you which version is live and which number your publication will get;
- publish the draft, and it becomes the next version.
Nothing is overwritten. Restoring version 3 creates version 7; it does not wind the history back to three entries. That is deliberate: a record of process changes that can be rolled back stops being evidence of what happened.
Where it is used
Beside each workflow the product shows how many projects run on it, how many issues stand in it, and whether it is the company default. That answers the question otherwise asked in chat: can I touch this process, and whom would it reach.
A workflow with issues in it cannot be deleted in passing. Archiving is a separate action, and it also takes the version.
What lands in the record
Creating a process, every publication, creating a status and archiving all land in the audit trail as entries with an author and a time. A publication is found there with the same filters as everything else.