Workflows let you mandate the review process a question and its answer must follow before it can be marked as complete.

They are how a team builds review gateways for different types of question, procurement and submission — and then reuses them, rather than relying on people remembering who should have checked what.

Workflows are optional. If you would rather manage review informally, assign editors and reviewers directly to questions instead. See Managing the question table.

In the left-hand sidebar, under Tools, click Workflows.

From here you can create a new workflow, or open an existing one to edit it. There is no limit on how many workflows your team can hold.

A workflow is a sequence of stages. Click Add Stage at the top of the view and choose the type:

A storyboard stage controls whether answers must be planned before they are written.

The requirement level determines whether the stage gates what follows it.

Only Required enforces anything. Recommended is a nudge, and teams under deadline pressure will pass straight through it — so use Required where the planning genuinely matters, and accept that Recommended will sometimes be ignored.

Each review stage is configured independently, so a workflow can tighten as an answer moves through it.

Choosing project team only means the people who can act at this stage are drawn from the team assigned to the project. That makes it important to configure the project team properly at creation — an incomplete team leaves a stage with nobody able to approve it. Organisation team roles are visible when you assign.

Choosing a group assigns the stage to a defined set of people instead. See Workflow Groups.

The edit policy sets what a reviewer can do rather than merely whether they approve:

Tighten the policy as the answer moves through the workflow. Direct edits are useful early, when an answer is still taking shape; formal sign-off suits a final gateway where the point is accountability, not improvement.

Toggle this on and reviewers must accept or reject every markup in the review room before the stage can record a completed approval.

This is what stops an answer being approved with unresolved comments still sitting in it — a common way for a reviewer's point to be quietly lost between stages.

Workflows do not have to be applied at project level. They can be assigned at three levels of granularity:

This matters because not all questions in a bid carry the same risk. A PQQ needs far fewer approval gateways than a large quality questionnaire.

Think about how much scrutiny each situation actually warrants:

Applying one heavy workflow across an entire bid is the most common mistake. It slows down the questions that did not need it, and teams start working around the process rather than through it.