Comments
Three comment types, each with different visibility:
| Type | Who can create | Who can see |
|---|---|---|
| Public | Signed-in members of the public with a verified email | Everyone |
| Staff Internal | Staff, Admin, Super Admin | Staff, Admin, Super Admin only |
| Review Note | Staff, Admin, Super Admin | Staff, Admin, Super Admin only |
Public
Submitted via the public portal by anyone with a community account (free sign-up, email verification required). The commenter's name comes from their account; the comment becomes visible to everyone and joins the permanent record. Staff can also record public comments received out-of-band — email, letter, phone, in-person — preserving the provenance channel on the row.
Staff Internal
Only authenticated staff, admins, and super admins see these. Use them for internal discussion — questions, concerns, or notes that shouldn't be public.
Review Note
Like staff comments, but specifically tied to the approval workflow. Approvers typically use them to explain why they approved or rejected an item.
Comments include read-status tracking, so staff can see which comments they haven't reviewed.
PII Handling
When the public sees comments, Livy removes the submitter's email, IP address, and browser info first. Staff see the full record. The public thread shows only the name and message — staff keep everything they need to investigate spam or follow up.
Moderation
Public comments move through a few states (live → hidden → either restored or permanently deleted), plus an admin-only option for malware or illegal content. Author self-withdrawals are a fourth path that skips the moderator controls.
The Three Moderator Actions
| Action | Verb in UI | Reversible? | Who sees it | Permission |
|---|---|---|---|---|
| Hide from public | "Hide From Public" | Yes (via Restore) | Hidden from the portal and the next rebuilt PDF; staff still see a placeholder | comment:moderate:public (admin+) |
| Delete permanently | "Delete Permanently" | No | Gone from everywhere, including the staff view; permanently removed | comment:moderate:public (admin+) |
| Restore | "Restore" | — | Brings a hidden comment back to its prior live state | comment:moderate:public (admin+) |
What the Public Actually Sees
When you "Hide from public", a top-level comment disappears entirely from the portal — no placeholder at all. The one exception: if the hidden comment has a reply that's still live (typically a staff reply to the now-hidden parent), a [removed by moderator] placeholder stays so the reply still makes sense. Without it, a public reader would see a staff reply with nothing it's responding to.
Hidden comments stay visible to staff as [removed by moderator] placeholders in the thread, so other staff have context at a glance while reviewing the item.
Reason Field — When Is It Asked?
One org toggle, two modes. No per-action exceptions.
| Mode | Hide From Public | Delete Permanently | Restore | Author self-withdraw |
|---|---|---|---|---|
| Default — org toggle off | Not asked | Not asked | Not asked | Never asked |
| Org has "Require reason" on | Required | Required | Required | Never asked |
The toggle lives at Settings → Meeting → Public Comments → Moderation. It's off by default so moderating is dead-simple out of the box: click the action, confirm, done. Orgs that want a written moderation trail flip it on and every moderator action — including restoration — requires context.
Author self-withdrawals are never affected. They aren't moderator actions, so the toggle never applies to them.
Why is Restore on the same toggle as Hide / Delete Permanently? A written restore-reason can read as legally sensitive in discovery ("we restored this because we shouldn't have removed it"). Orgs that opt in are deliberately accepting that cost in exchange for a complete moderation trail; orgs that don't turn it on never see a reason field anywhere on the moderator path.
Audit Trail
Every moderation action is recorded in the audit log with a 100-character preview of the comment. The per-item Changelog tab shows them with distinct wording:
- "Comment hidden from public" — a moderator hid the comment; trailing "— Reason: …" when the org toggle is on
- "Comment deleted permanently" — a moderator permanently deleted it; same Reason suffix when the toggle is on
- "Comment restored" — moderator restore; same Reason suffix when the toggle is on
- "Author withdrew their comment" — author self-withdraw; never carries a reason
Permanent delete is the only path that destroys the comment itself. The audit entry stays (with the 100-character preview); the original text is gone.
Who Gets Notified
No one is notified of any moderation action. The original commenter is never told their comment was hidden, deleted, or restored — they find out only if they come back to look. Other admins aren't notified either; moderation activity shows up in the Changelog tab when staff look. This is deliberate: pinging people about moderation would create more anxiety than transparency.
PDF Updates
Hiding, deleting, or restoring a comment on an item that's on a published agenda automatically queues the packet PDF to rebuild. The public PDF picks up the change shortly after (typically within minutes). Nothing rebuilds when the item isn't on a published agenda or the org's PDF comment mode is off.
Author Self-Withdraw
A commenter who clicks "Withdraw" on their own comment from the public portal hides it — the same hide-from-public behavior a moderator's action produces (it vanishes from the portal unless a staff reply is attached). The author-facing word is intentionally "Withdraw" rather than "Delete" — the comment is kept for staff audit, so "Delete" would mislead. Authors can't use the "Delete Permanently" option; that's admin-only. Authors can't restore their own withdrawn comment either — that's an admin action.
Related
- Permissions & Roles — who can read each comment type
- Approval Workflow — review notes are commonly used by approvers