Review comments
Leave inline comment threads on a submitted draft, reply, resolve or reopen them, and understand how threads attach to the exact version reviewed.
Review comments are threaded discussions attached to a single block of a submitted draft. Use them when a document needs specific, quotable feedback rather than one overall verdict — an approver marking three paragraphs to fix, an author answering each one.
Leaving a comment
Comments live on the review screen: Governance → a document → Review. Hover a block and choose Comment on this block, type into the comment box, and post it. That opens a new thread anchored to that block.
Each comment can be up to 4,000 characters. There is no draft state — posting is immediate and visible to everyone who can read the document.
Replying
Open a thread and use the Reply box. Replies are ordered oldest-first under the original comment, and the thread shows a reply count so you can see at a glance which points are still being argued.
Resolving and reopening
A thread is either open or resolved.
| Action | Effect |
|---|---|
| Resolve | Marks the point as settled. The thread collapses to a "Resolved" state but keeps all its comments. |
| Reopen | Puts a resolved thread back to open. |
Either side can do either — the approver who raised the point and the author fixing it both have the same buttons. Nothing is deleted by resolving, and reopening restores the thread exactly as it was.
Who can see and act
| What you can do | Role needed on the document's team |
|---|---|
| Read every thread and reply on the document | Reader or higher |
| Start a thread, reply, resolve, reopen | Writer or higher |
Readers are strictly read-only here: they see the whole discussion but have no comment box and no resolve control. Team membership is what grants access — someone outside the document's team sees nothing. Workspace Owners and Admins count as Owners on every team, so they can always comment.
How threads relate to the draft they were left on
This is the part worth reading carefully, because it decides where your comments will be tomorrow.
When you request approval, Alchex freezes the draft into an immutable snapshot. Comment threads anchor to that specific snapshot, not to the document in general. The snapshot never changes, so a thread always points at exactly the text that was under discussion — the quoted passage cannot drift as the document is edited afterwards.
The consequence:
- Threads survive. They are never deleted by a decision. Nothing you write in a review is lost.
- Threads do not carry forward to the next submission. When the author edits and submits again, that creates a new snapshot. The older threads stay attached to the older snapshot and stop appearing on the current review screen. The new approver starts with a clean slate.
So the review screen always shows the discussion on the draft currently under review — never a pile-up from earlier rounds.
After Request changes, the author does still see the threads from the round that was sent back: they appear as a review comments strip under the change-request note, above the editor, with a count of how many are still open. That strip is the author's punch list. Once they submit again, the strip's threads move out of view along with the snapshot they belong to.
Practical advice
- Resolve as you go. The open count on the sent-back strip is the fastest signal of whether a round of changes is finished.
- Say what should change, not just what is wrong. Your comment is read alongside the frozen text, often by someone who did not write it.
- Use the decision message for the verdict. Request changes carries one message to the submitter; keep the block-by-block detail in threads.
- Deleting the document deletes the comments. A document delete is permanent and takes the draft, published versions, history and review comments with it.
Related: submit and approve, versions, collaboration, permissions.