Comments
Leave a comment on a passage of a live draft, reply, and resolve it — margin conversation that moves with the text as the document is edited.
A comment is a note attached to a specific passage of a draft you are still writing. Select the words, say what you mean, and the passage carries a quiet highlight until somebody resolves it. Use comments while the document is being written — to query a sentence, flag a gap, or agree who is fixing what — without putting any of that into the document itself.
Leaving one
Open Governance → a document → Document, select the text you want to talk about, and choose Comment on the toolbar that appears over the selection. Type the comment and post it.
Selecting text first is the only way in, because a comment is attached to a passage and needs to know which one. The Comments panel says so when it is empty — it lists conversations rather than starting them.
The passage now carries a highlight. Clicking into it opens the thread: the messages so far, a reply box, and Resolve.
Each comment can be up to 4,000 characters. Posting is immediate — there is no draft state.
If you can read the document, you can comment on it. Commenting is not an editing right: a reviewer or auditor with read-only access can ask a question, and often is the person who needs to. You may edit or delete your own words and nobody else's. Anyone who can read the thread can resolve or reopen it — settling a conversation is not the same act as writing in it — and the person who resolved it is recorded on the thread. Registers and risks work the same way; there is one rule across every place you can comment.
Replying and resolving
| Action | Effect |
|---|---|
| Reply | Adds to the thread. Replies read oldest-first under the first message. |
| Resolve | Marks the point as settled. The highlight disappears from the text and the thread moves to the resolved list. |
| Reopen | Returns a resolved thread to open. |
Two things about this are worth knowing before you rely on them.
Resolving removes the highlight. The thread is kept in full — nothing is deleted — but the passage stops being marked, because the conversation about it is over. That is the point of resolving.
Reopening brings back the thread, not the highlight. Once the highlight is gone, there is no longer a passage recorded as being under discussion, so a reopened thread comes back as a record rather than as a mark in the text. If the point still needs to be visible in the document, comment on the passage again.
Replying to a resolved thread does not reopen it. "One more thing about this" and "this is not settled" are different, and only the second one should change the open count. Use Reopen when you mean it.
Naming someone
If a comment or reply names a teammate, that person gets a notification carrying the document, who wrote it, and a short preview — so a question asked in the margin reaches the person it was asked of, instead of waiting for them to reopen the document.
This works everywhere you can comment, not only on documents: naming somebody on a risk, on one of its actions, on a register record or on a control reaches them the same way. The notice names whatever the comment is on — a document by its title, a risk by its code, an action by its own title, a register record by its register — and opens straight to it. A control is the one exception: it has no page of its own to open, so the notice tells you and stops there.
There is no @ picker on a live draft yet. The picker ships on the review comment surface, which Alchex draws itself; the live-draft comment panel comes from the editor, and will get one when the editor does. Until then, mentions written on a draft are notified but not offered — so in practice, name people in review comments.
Mentioning yourself never notifies you, and naming the same person several times in one comment reaches them once.
Who can do what
| What you can do | Role needed on the document's team |
|---|---|
| Read every thread on the document | Reader or higher |
| Comment, reply, resolve, reopen | Reader or higher |
| Edit or delete a comment | Its author only, at any role |
Reading is the whole permission: if you can see the record, you can join and settle its conversation. What role never grants is authorship — your words are yours, and nobody else's to rewrite or remove. Workspace Owners and Admins count as Owners on every team, so they can always comment. See Permissions.
Your name on a comment is your account's display name — it is recorded when you post, so a comment keeps the name you had when you wrote it.
Comments Alchex leaves
When you approve an edit the assistant proposed, it comments on what it did — in this same margin, as a thread you can reply to and resolve, not as a separate machine log.
There is one comment per section it changed, anchored to the passage it changed, and each one says three things: what it did, why, and where the change came from. "I rewrote Access review. You asked for the review to run quarterly rather than yearly. I made this while we were talking — the reasoning is in that conversation."
- The comment is attributed to Alchex, not to you, even though you are the person who approved the change. A note about a machine's edit that carried a colleague's name would be a lie about who wrote it.
- Every edit is commented on, not the ones a machine judged significant — including edits made in the same step as publishing a new version, so the explanation travels with the change to everyone who reads it. See Publishing.
- If the edit removed a section outright there is nowhere left to anchor to, so the thread carries the name of the section it targeted instead of a highlight, exactly as a person's thread does when the passage it was left on is deleted.
- Your own typing is never commented on. The margin is for conversation, not for a log of keystrokes.
Resolving these is still your job, with one exception. When a comment flagged that a register the section cites is still holding rows nobody has confirmed, confirming the last of those rows settles precisely what the comment asked for — so the thread resolves itself, and Alchex leaves a closing message saying why. It is recorded as resolved by the person who confirmed, because a person did settle it, and you can reopen it like any other thread. Nothing else resolves on its own. See Registers.
Comments move with the text
A comment is anchored to the words, not to a position. As you and your colleagues edit around it — inserting paragraphs above, rewording the sentence before it — the highlight travels with the passage it was left on. Live co-editing does not disturb this: two people can be typing elsewhere in the document while a thread stays exactly where it belongs. See Collaboration.
If the commented passage is deleted outright, the highlight goes with it. The thread itself survives, and keeps the exact words it was originally left on, so the conversation can still be read and understood. It simply has nowhere in the current text to point at any more.
Comments are not review comments
These are two different surfaces and it matters which one you are in.
| Comments (this page) | Review comments | |
|---|---|---|
| Where | The live draft, while it is being written | The review screen, on a submitted draft |
| Anchored to | A passage of text, which moves as you edit | A block of the sealed copy, which cannot change |
| Lifetime | Belongs to the document | Belongs to that round of approval |
| Use it for | Working the draft out with your co-authors | Telling an author what to change before you approve |
A comment left while drafting stays with the document through submission and publication. A review comment belongs to the round it was raised in and stops appearing once a new draft is submitted.
Practical advice
- Resolve as you go. An open thread is a claim that something is unfinished; leaving settled ones open makes the count meaningless.
- Comment on the passage, not the document. The whole value is that the reader sees exactly which words you meant.
- Don't use comments to record decisions. Once resolved they are out of the way by design. A decision that has to survive belongs in the document, or in its history.