Workflows in documents

A workflow is not a separate thing you build beside your procedure — it is built from what your procedure says. You write the process as you always have, in plain sentences; the builder reads that text and composes the steps it describes. The document stays pure prose — nothing is inserted into your sentences — and the workflow lives in the Workflow panel, where you review it, accept it, and watch it run. Accepting is what makes it live — there is no separate switch to throw.

The clearest procedure ends with one short section that says how it runs — its review cadence, what each review verifies, and what happens when a gap is found (the marketplace's documents close with exactly such a "How this … runs" section). That is the builder's best input: if the workflow the builder proposes looks complicated, the fix is the text — state the loop plainly in one place and build again.

Building the workflow from your prose

You do not have to place steps by hand. Write the procedure the way you think — "reviewed every 12 months", "the leaver list is kept in our HR system; check every leaver's access is revoked", "if the review finds a gap, raise a risk" — and press Build the workflow in the Workflow panel. The builder reads your prose and proposes the steps it describes, using only what your workspace actually has: the step kinds on this page, your connected sources, your record kinds' real fields, your team's roles. Reading a whole procedure is real work — a build takes a minute or two; the panel says so while it runs, and the proposal appears there when done.

The proposal is a plan, not a change. Each proposed step shows as the same short phrase the Steps tab will use, with a note and the sentence of your procedure it came from — click a step and the document scrolls to that sentence. Where the procedure leaves something unsaid, the builder asks instead of guessing: no cadence stated, a system named that is not connected, a person it cannot identify — each becomes a question, listed under the plan with its choices where a closed set exists. Answer by fixing the prose (or connecting the system) and building again.

Add these steps stores the plan as the document's workflow — the Steps tab shows it from then on. Your text is untouched: the workflow is kept with the document, not written into it. From that moment the workflow is live — for a schedule, the first period still has to pass before its first run. Building spends from your workspace's AI allowance; accepting is free.

The step kinds

Steps reach a workflow one way: Build the workflow proposes them from your prose, and you accept. (Hand-placing steps in the text — chips from the / palette, and later the panel's Add the first step button — is retired: the document is prose, and the workflow is kept beside it. A document that still carries chips from that era keeps running on them, and its next accepted build replaces them with the stored workflow and clears them from the text.) These are the step kinds the builder composes from, on every governance document, a control's own procedure included:

• When a record… — a trigger. The workflow starts when a record of the kind you choose is created, or submitted for review. For documents you can narrow it to a single document type — chosen from the same list of types your documents already use, or left as Any document type — so one procedure can govern every record of that type.
• Ask for approval — a person decides here. The run files a request in that person's My Approvals and waits; only a person can decide it, never the system.
• Set a field — updates one field on the record the run is about, exactly as if a person edited it (the record's own history shows the change). The field is picked from the record's own fields, never typed from memory.
• Create a risk — opens a risk in your register: numbered like any other, with its own history, and linked back to this procedure so the register says where it came from. You can have it act always, or only when a check finds a gap — a minor or major non-conformity from a Check a requirement step earlier in the run. A check that could not tell (needs evidence, cannot assess) never opens a risk. A dry run creates nothing.
• Read a connected source — fetches the current records behind one of your connected sources (picked from your connections, then the source — never typed) and attaches them to the run, so every Check a requirement after this step judges them too. This is how "we keep the data in another system — observe it, check it" becomes a procedure: read fetches, check judges, and the run's receipt records exactly what was read (the source and a fingerprint of its content). Reading changes nothing in the connected system. If the source cannot be fetched when the run reaches it, the run fails and says so — a check never quietly judges less than the procedure promised. A run reads at most eight sources.
• Notify someone — an inbox notice to the record's owner, a team role, or a specific person. Like Create a risk, it can be set to act only when a check finds a gap.
• Only if… — the run continues past this point only when a field of the record matches the value you set. The field is picked from the record's own fields, like Set a field.
• Run on demand — the workflow starts when a person presses Run now, with no record event involved. Use it for a procedure you want to run when you decide to, like checking a control. It has nothing to configure: anyone who can edit the procedure can run it.
• Every… — the workflow runs itself on a cadence: every N days, weeks or months. This is the trigger review sentences are written in — "reviewed every 12 months" becomes one step. The first run lands one full period after you accept the step, and each later run one period after the last; the run judges the procedure document itself, exactly as a Run on demand run does, and leaves the same receipts. Re-accepting without changing the cadence keeps the clock; changing the cadence starts it fresh from that moment. Archiving the document stops it.
• Check a requirement — write one obligation in your own words and say which depth has to be proved: that it is documented (written down), implemented (actually done) or effective (working). When the run reaches it, the requirement is judged against the record the run is about and the verdict lands on the run's receipt. You can also say which clause the requirement answers for, and then the verdict updates where you stand on that clause — see A check that answers for a clause below.

Each step reads as a short phrase — "When an evidence record is created", "Ask the admin role to approve" — derived from its settings, so the panel stays readable.

Changing the workflow

The workflow is changed the way it was made: change the text, build again. State the new cadence, the new approver, the extra check in the procedure's own sentences and press Build — the builder proposes the updated steps, and accepting them replaces the workflow. There is nothing to configure outside your prose, and the same guardrails hold either way: a step may only name a field its record actually has (accepting a plan that does not is refused, naming the step and the fields it may use), and only a connected source your workspace really holds. (A register record's columns are your own, so there the field stays free text and a wrong name is reported by the run.)

Accepting is what puts the workflow into service. From the next matching event on, the steps you accepted are the steps that run.

Running a procedure yourself

A procedure carrying a Run on demand step gets a Run now button at the top of the Workflow panel's Steps tab. Pressing it runs the steps straight away and the result appears in Runs, with the same receipts every other run leaves.

Two things it will refuse, and say so:

• The workflow has no Run on demand step. Add one and accept the build.
• The document is archived, or has no steps to run.

When it runs, the procedure document is its own subject — a Check a requirement step in it judges the document itself. That is what makes a control procedure able to check its own control.

Accepting is the switch — archiving is the only off

A document is active from the moment you create it. There is no draft state it has to leave and no publish step that switches it on: once you accept a workflow, it is live, and from the next matching event on its steps run. Accept a new build and the next run follows it; runs already in flight finish on the steps they started with, and their receipts say exactly which version they ran.

Archiving the document is the one thing that stops its triggers. Archive a procedure and it stops acting the same moment, with no window in which a retired document still fires.

Versions and approvals are still yours to use — a document carries a version number, and can carry an approval — but neither is a switch. They record what the procedure says and who agreed to it; they do not decide whether it runs.

Whether it can fire is never a guess. Every read of a document's workflow now carries its liveness — whether the engine actually holds trigger rows for it (armed), and for a scheduled workflow, when the next fire is due. A workflow on a cadence does nothing until its first period elapses; the next-fire time makes that silence a stated date instead of a mystery.

The Workflow panel

Every document has a Workflow button among its panel doors, whether or not it has a workflow yet. On a document with none, the panel offers the way in: Build the workflow, which reads your prose and proposes the steps it describes.

The panel has two tabs:

• Steps shows the accepted workflow as short phrases, in run order. An Only if… condition opens a labeled lane — an indented path headed by its condition — holding the steps that only run on that path, so a branching workflow never reads as a misleading flat list.
• Runs lists what actually happened, newest first: each run says its outcome — completed, waiting on a decision, failed — with the document version it ran from and the date, and expands to its per-step receipts. Every step leaves one, and a Check a requirement step's receipt carries its verdict in full. The panel shows where runs are; deciding an approval stays in My Approvals.

What a check actually looks at

A check reads the record the run is about — a document's published text (its draft, if it has never been published, and the receipt says which), a register row's cells, or the fields of an evidence or risk record — plus whatever the run's Read a connected source steps fetched before it. It does not search the rest of your workspace. That bound is deliberate: a check answers "does this record meet this requirement", and one that quietly reached further would answer a question you did not ask. A connected source is never a quiet reach — it is a visible step the procedure itself placed, and the run's receipts say what was read.

One more thing worth knowing about connected sources: they are always judged at their current content. A run that waited on an approval re-reads its sources when it resumes — and leaves a receipt saying it did — rather than judging records fetched before the wait.

Its verdict is one of:

• Met — the evidence shows the requirement is satisfied at the depth you asked for.
• Minor or major non-conformity — it is not, and why.
• Observation — a weakness worth recording that is not yet a non-conformity.
• Needs evidence — there was nothing readable to judge. This is an honest "I could not tell", never a quiet fail: a check that found nothing says so instead of accusing the record.
• Cannot assess — the check could not run (the AI service was unreachable, or the workspace has no AI allowance left). Again, not a fail.

A check records; it does not act on its own. The verdict goes on the run receipt — it does not change the record, open a risk, or stop the run. Steps after a check run exactly as they would have. When you want a gap to do something, that is its own step, placed after the check: a Create a risk or Notify someone set to act only when a check finds a gap. The acting is always a step you can see in the sentence, never a side effect of judging.

The two things a verdict does reach are described below.

A check that answers for a clause

A requirement is written in your own words, so nothing about it says which part of a standard it satisfies. When it does answer for one, say so: the check's editor offers your standards and then that standard's clauses, as two lists to pick from.

Naming a clause changes one thing. As well as landing on the receipt, the verdict is recorded as where you stand on that clause — so the clause shows as conforming, as a gap, or as needing evidence on your compliance page, and your readiness moves with it. That is how a document you wrote counts towards a standard without anyone auditing it separately: the procedure that governs the document checks its clauses, and the number knows.

Naming a clause is optional and leaving it unset is the ordinary case — a control's procedure grading its own obligations usually has no clause to name, and its checks simply leave receipts as before.

Three things bound it:

• The three verdicts that are not a pass are recorded honestly. A minor or major non-conformity, and an observation, all record the clause as a gap — a clause with a live weakness is never shown as passed, whichever surface found it. Needs evidence records that the clause still needs proof, which is not the same as never having been looked at.
• A check that could not run records nothing. If the AI service was unreachable or your workspace has no AI allowance left, the clause keeps whatever it last knew. An outage never lowers your compliance number.
• The most recent check wins. One clause holds one answer — the last run to check it is what your compliance page shows, along with the document it read and when.

The other thing a verdict reaches is described below, and only from a run you started yourself.

Two limits worth knowing: every check spends from your workspace's AI allowance, and one run evaluates at most sixteen checks — beyond that the receipt says the step was not judged rather than silently skipping it.

Running a control's own procedure

If the procedure you run is a control's document, the run also files an audit report against that control, made from its check verdicts.

The report is a draft, recorded on the control's record — the Workflow panel says so as soon as the run finishes, and the run's own receipts in Runs carry a finding per check step: its verdict, why, and the evidence it was read from. Nothing a workflow run decides is published on its own — a check that names a clause updates that clause's standing, and everything else is a record, not a status change.

Three things bound this, and they are worth knowing:

• Only a run you started files a report. A workflow triggered by a record event never does — it fires once per matching record, so it would file a fresh report every time anything passed through the procedure.
• Only a control's own procedure files one. Running any other document's workflow files nothing, which is the ordinary case and not an error.
• If the report cannot be written, the run is unaffected — its receipts are already saved. You lose the report, never the run.

Where you see it

• A record whose kind or type a workflow listens to shows a Workflow row in its details, naming the governing procedure — derived automatically; there is nothing to configure.
• Approval steps appear in the decider's My Approvals, like any other review.
• Notifications land in the inbox, named after the procedure that sent them.