Publishing
How a draft becomes the version your readers see, who is allowed to publish, and what stays fixed afterwards.
A version is a record, not a gate. Your document is live from the moment it exists: what it says now is what your readers, your processes and the assistant read. Publishing keeps a numbered, immutable copy of that text for the record — the version an audit cites — and is the door a document-control workflow's Ask for approval step uses when your own procedure says documents must be approved. Nothing waits for it: the processes built from the document act on their own switch (see Authoring → Workflows in documents). Publishing mints the next version of a document — the fixed, approved copy your readers are pinned to from that moment on. Once a document has one, readers keep seeing it until the next one publishes, so you can edit freely without changing what the organisation is following.
A document does not need publishing to exist. It is active at v1 from the moment it is created and its readers can read it straight away; publishing is how a version is approved and how the label steps forward, not how a document is turned on. See the lifecycle.
What publishing does
When a document publishes, three things happen together:
- The current draft content is captured as a published version and given a version label. The label is a count, so a document at v7 publishes as v8 — nobody is asked for a number.
- The document's published pointer moves to the new version. Anyone with read access now sees it.
- A fresh working draft opens on top of the new version, so editing can continue immediately.
Publishing does not switch a workflow on. A document is active from the moment you create it, and accepting its workflow is what makes it act — from the next matching event on, the accepted steps run, published or not. Runs already in flight finish on the steps they started with, and archiving the document stops its triggers.
The record itself says which is which: the Status row names the version in force, the Activity trail carries who approved it and when, and a Word export's generated Document control tables state the same facts on paper. Before a document's first approval there is no separate version for readers yet — what you are writing is what they are reading, and the first approval publishes v2.
An undecided proposal from the assistant is not part of the draft either. Work it wrote for a part somebody had already changed waits on the document's Assistant proposals panel until a person applies it, so a publish captures what is actually in the document and never carries a proposal nobody decided into the version readers see. See AI review and assistance.
Editorial or material
The system cannot tell a typo from a change of policy, so the person publishing can say — but is never made to answer. Every publish is an editorial change by default: wording, formatting, a correction that leaves the meaning alone; the version simply counts on, so v7 becomes v8. Published and hand-saved versions count up the same chain — if somebody saved v8 from the panel this morning, your publish mints v9 — so a version's number always places it in the document's one story. See Version history. When the substance moved and readers need to notice, tick Material change on the review surface before you approve: the number is the same either way — what the tick changes is what the record SAYS about the change, so a reader can see at a glance which versions moved the substance. Every label on the surface updates the moment you tick it, so the button you press names exactly what publishes.
Whichever way it lands, the version label is minted when the publish lands and never changes afterwards. A document's first publish has nothing to be material relative to, so the toggle does not appear for it.
The same quiet choice exists on both routes below: an approver may tick it when they approve, and the server's direct-publish verb takes it as a parameter.
Two routes to publish
| Route | Who starts it | Who publishes | Logged as |
|---|---|---|---|
| Approval | Anyone with Writer or Owner on the team submits for review | An Owner who is not the submitter approves, and the approval publishes | approval |
| Direct publish | The server's publish verb — administrative tooling or the automation layer; there is no button in the app | The Owner the verb runs as | self-publish |
Approval. Submitting takes an immutable copy so the approver reviews exactly the content that was sent (see Submit and approve). Approving publishes that copy in the same step: there is no separate publish click afterwards, and the submitter is told it went out and at which version. See Submit and approve.
Conversation about the submitted copy happens where every conversation happens — the document's Comments panel. Raise your points there, and keep the change-request note to the one sentence that says why the document is going back.
Direct publish. An Owner can publish their own draft without a second person. Open the document, choose Review & publish, read the change summary (open View changes for the block-by-block comparison), then press Publish v8 — one click, no confirmation step after it. This is the one sanctioned self-approval in the system and it is recorded as such: the activity log stores the publish as a self-publish. If you would rather have a second pair of eyes, have a review opened (see how a review is opened) and let another Owner decide it on their My Approvals page. Direct publish. The current draft can be published without a review — but only through the server's publish verb, at the Owner rung; the app offers no publish button anywhere. It is the one sanctioned self-approval in the system and it is recorded as such: the activity log stores the publish as a self-publish. The route a person takes is always the review: have one opened (see how a review is opened) and another Owner decides it on their My Approvals page.
Where approval state shows on a document
There is no approval panel on records. A document tells its approval story in three places, each doing one job:
- Document control (in the Details panel): the standing facts — the version in force, who approved it, when it took effect, and In review — requested by … while a request is open. A label, never a workflow.
- Activity (its button in the document's top bar, beside the other panel buttons since August 2026 — the panel itself still opens on the right edge): the full trail — every request, approval, send-back and withdrawal, permanently, with who and when.
- The ⋯ menu: no approval act at all — copy link, Download (the same window every record kind opens, where the Version control decides whether you take the approved copy or the draft), archive. Reading a pending review's comparison happens from My Approvals, the same place it is decided.
Decisions are made on My Approvals, the one decide surface; reviews are opened with no button at all, and published the same way — approving is what publishes. See how a review is opened.
Who may publish
| Team role | Edit the draft | Submit for review | Approve someone's review | Publish directly |
|---|---|---|---|---|
| Reader | No | No | No | No |
| Writer | Yes | Yes | No | No |
| Owner | Yes | Yes | Yes, unless they submitted it | Yes |
Workspace owners and admins act as team Owners on any team's documents.
Two guards apply and cannot be overridden by any role:
- Separation of duties. The person who submitted a review cannot approve it. A workspace owner who submitted is still refused. Another Owner has to decide it.
- A pending review blocks a direct publish. While any approval request is open on the document — your own included — direct publish is refused: decide or withdraw that review first. This is the record lock, the same rule that holds every other write still while a reviewer reads.
If you lack the role, the app tells you plainly: publishing needs the team Owner role. Ask a team Owner.
Working with the assistant on a version
Publishing is yours, not the assistant's. Approving, publishing, and saving a version are actions people take — on My Approvals, from the document's ⋯ menu, and in version history. The assistant does not take them for you and has no way to.
What it does is the writing that leads up to them. Ask it to change a section and it proposes the edit as a diff you approve; once the draft says what you want, you publish it by the routes above. You start that conversation from Chat in the sidebar and pin the document with the ⌖ picker in the composer, which resumes the conversation you were last having about it. (A ✦ button in the document's own bar did this until September 2026; a record carries no button onto the assistant any more.)
It also knows the route. Ask "can we get this live?" — as a Writer or an Owner — and it tells you the truth: a draft reaches readers through a review decided on My Approvals. Nothing about your draft changes until that decision is taken.
The explanation travels with the change: every section the assistant edited is left with a margin comment from Alchex saying what it changed and why, so the reason lives beside the words rather than only in the chat that produced them. See Comments.
Returning the draft to an earlier point does not publish
Restoring an old version, or returning to an editing session, changes the draft only. Readers keep seeing the version in force until you publish a new one, and the published history keeps every step either way. It is also allowed while a review is open: a reviewer decides on the exact content their request pinned, and the draft cannot reach it.
Publishing an uploaded file
A document whose content is an uploaded file does not publish this way at all: it has no draft, so the upload itself is the publish, and replacing the file publishes the next edition. Nothing below applies to one. The rest of this section describes the review you can still ask for voluntarily on a file-backed record that has not published yet — where what you read before confirming is the file itself rather than a change list — there is no line-by-line comparison to make between two files. Ask another Owner works exactly as above. The editorial-or-material choice does not apply: you cannot make an editorial correction to a PDF somebody else issued, so an uploaded file counts on like everything else — v1, v2, v3 — and Alchex mints the next one rather than asking. The published version keeps the file's fingerprint, so what was approved is provably what shipped. See External documents.
Nothing to publish
If the draft is identical to the published version, the panel reports Nothing to publish. Make a change first, or close it. For an uploaded file the same message appears when the current file is byte-for-byte the published one — upload a different file to publish again.
An archived document publishes nothing either, and decides nothing: it is read-only, and its ⋯ menu offers no publish or review door until the document comes back. Restore it from the banner at the top of the document and the workflow resumes where it was. See Activity and archive.
Placeholders have to be filled in first
A document cannot be published while it still carries bracketed placeholders — [the approving role], [number] business days — the kind a template or a generated draft leaves for you to complete. The review surface names what is still open before you press anything and holds the publish button until it is resolved; and if a placeholder slips through any other door, the publish itself is refused with the same list.
This is a refusal rather than a warning on purpose. A warning at publish time is read by someone who has already decided to publish, and the cost of getting it wrong is not cosmetic: an issued procedure that tells its reader to insert a value is one nobody can actually follow, and in an audit it reads as a control that was never specified.
Three things that look like placeholders are not, and never block publishing: a reference chip, a link, and a bracketed number or date such as [12] or [2026-01-01]. Only brackets containing words are treated as an instruction left for the author.
A second refusal of the same kind guards workflow chips: a Set a field or Only if… step that names a field its record does not actually have is refused at publish, and the message names the chip and the fields it may use. So is a Read a connected source step naming a source your team does not hold — or one that has been archived. The alternative — letting it publish and discovering the mistake as a failed run some weeks later — is exactly the silence a publish gate exists to prevent. All of these refusals run on the same pinned copy, on every path a publish can take.
The check runs on the exact version being published — the copy pinned when the document went for review, not whatever the draft says at the moment somebody presses Approve. So what was checked and what gets issued are guaranteed to be the same text. It applies to both routes equally: publishing directly and approving a review.
What a published version means
A published version is a fixed record, not a live pointer into the draft. It keeps the exact content that was published, its version label, who published it, and when.
- Published versions are immutable. Nothing in the app can edit or overwrite one — not an Owner, not a restore, not a later edit.
- Older published versions are retained, never hidden. They stay readable in version history and are marked Superseded; the one readers see is marked Current.
- Editing after a publish never touches what readers see. The new work sits in the draft until it publishes in turn.
No document can be deleted, published or not. That used to be a rule about publishing — from the first published version onwards, the delete action disappeared and the API refused it, because the versions, approvals and activity trail are the record. It is no longer conditional on anything: there is no delete action and no delete endpoint, for a published document or a draft that never left its author's hands.
Removing a document means Archive: it keeps every version, stays readable and auditable, and Restore on its banner brings it back. See Activity and archive.
What the document rests on
A control publishes the same way as any other document — and publishing is what puts its definition into effect: the audit runs against the published version, never the draft you are still writing.
Because that distinction decides whether a run means anything, a control's audit rail says which side of it you are on. It carries no publish button — nobody's role summons one, here or anywhere else — the rail simply states the basis, and the fix is the same as everywhere on this page: a review decided on My Approvals, or the server's publish verb.
Once the publish goes through, the rail catches up on its own: the definition it judges against is the one that was just published, and it says so without a page refresh — including when you published from the approval panel that replaced the rail while you were confirming. The same is true when a review is approved: approving is what publishes. See Controls and evidence.
Publishing a control also tidies up behind it. Files the control's text no longer cites are collected at the same time, and only when nothing anywhere else still points at them. The sweep never reaches outside the document's own team, and it never touches a connector label — a label outlives the sentence that cited it, because a workflow or another team's control may be reading the same source.
The document's panel carries Backed by — the evidence the document itself references. It is worth a look before you publish: it is the list an auditor would ask for, and a document that references nothing reads as Backs nothing yet — unproven. Publishing does not change the list; it is derived from the text, so it follows whatever the published body says. See References.
Related
- Version history — browsing, comparing and restoring past versions.
- Comments — commenting on a passage of a live draft.
- Comments — the record's one conversation, reviews included.
- Permissions — the full role matrix.