Publishing
How a draft becomes the version your readers see, who is allowed to publish, and what stays fixed afterwards.
Publishing turns the working draft into the version everyone else reads. Until a draft is published, readers keep seeing the last published version — you can edit freely without changing what the organisation is following.
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. Each publish moves the label on by one minor step, so a document at v1.2 publishes as v1.3.
- 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.
The state chip on the document says which is which: while you are editing, it reads Draft · readers see v1.2, and tells you the version the draft will publish as.
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 | An Owner opens Review & publish on their own draft | The same Owner publishes | self-publish |
Approval. Submitting freezes the draft so the approver reviews exactly the content that was sent. Approving publishes it in the same step — there is no separate publish click afterwards. See Submit and approve.
Direct publish. An Owner can publish their own draft without a second person. Open the document, choose Review & publish, read the change list against the published version, then choose Publish v1.3. This is the one sanctioned self-approval in the system and it is recorded as such — the dialog says so, and the activity log stores the publish as a self-publish. If you would rather have a second pair of eyes, Ask another Owner in the same dialog sends it for review instead.
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. If someone else's approval request is open on the document, direct publish is refused: decide or withdraw that review first. Your own pending submission is simply superseded when you publish directly.
If you lack the role, the app tells you plainly: publishing needs the team Owner role. Ask a team Owner.
Nothing to publish
If the draft is identical to the published version, the dialog reports Nothing to publish. Make a change first, or close the dialog.
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 Obsolete; the current one is marked Active.
- Editing after a publish never touches what readers see. The new work sits in the draft until it publishes in turn.
Deleting the document is the one action that removes published versions, and it is permanent. Archiving does not: an archived document keeps every version and stays readable and auditable. See Activity and archive.
Related
- Version history — browsing, comparing and restoring past versions.
- Comments — review threads on a sealed draft.
- Permissions — the full role matrix.