Notifications

CompassDocs can push an alert to your chat platform or inbox when content changes hands. Admins manage everything under Settings → Notifications — available in every edition.

Channels

Add as many channels as you like; each has its own events and space filter.

Channel	How to connect
Webex	Create an incoming webhook for the target space and paste its URL.
Microsoft Teams	In Teams: channel → Workflows → Post to a channel when a webhook request is received, then paste the workflow URL. Alerts render as Adaptive Cards.
Slack	Create an incoming webhook and paste its URL.
Email	Enter one or more recipient addresses (comma-separated). Requires SMTP, below.
Generic JSON	Any endpoint that accepts a JSON POST — for your own automation.

Webhook URLs are stored write-only — after saving, the UI shows only the hostname. Every channel has a Test button that sends a sample alert, and the list shows each channel’s last delivery status and time, so a revoked webhook or broken relay is visible at a glance.

Events

Each channel subscribes to any of:

• Change submitted for review — an editor’s change request enters the review queue. The classic “something needs an approver” ping.
• Change approved / Change rejected — the review decision, with the reviewer’s note.
• Document published — a doc goes live directly (from the app or the Claude connector).
• Suggestion left — a reader files a suggestion, with a preview of the text.

From 1.14.0, while read confirmations are licensed, the checklist also lists five Compliance events under their own heading, so a #compliance channel hears what the read confirmation programme is doing:

• Read confirmation requested — a policy starts asking people: it was required with notice, everyone was asked to re-confirm, an audience save added people, a set was assigned, or an annual cycle started. Once per policy: Priya Shah asked 412 people to confirm “Acceptable Use Policy” by 29 Oct 2026., or for a cycle Annual re-confirmation of “Acceptable Use Policy” started: 412 people to confirm.
• Confirmation deadline approaching — the hourly sweep finds a live policy whose next deadline is inside its days before due window (the policy’s number, else its space’s, else Program settings’); once per policy per due date: “Acceptable Use Policy” is due in 3 days: 88 people still to confirm.
• Confirmations overdue — the escalation sweep escalated someone on the policy; once per policy per sweep: 7 people are more than a week overdue on “Acceptable Use Policy”.
• Compliance summary — the first hourly tick of each ISO week, one message per channel, only to channels with no space filter: Policy compliance this week: 94% · 23 overdue across 4 policies · lowest: Data Handling 71%. and, when the month’s evidence snapshot has been taken, Monthly snapshot sha256 a1b2c3…
• Policy retired — a policy is retired from its Lifecycle card: “Travel policy” was retired by Priya Shah; replaced by “Expenses and travel”.

A channel saved with one of these keeps it even if the licence lapses (it then simply never fires).

Counts only, never names. These messages carry the counts and the policy’s title and never the names of the people who have not confirmed; those go to the policy’s owner and to group leads through the escalation and reminder notices, and to nobody else. The one name a message may carry is the manager’s who asked or retired the policy. Every event is sent once per policy, after the notice to the people themselves has been queued, and never waits on the channel: a slow or dead endpoint never slows a Request or a retire; deliveries show on the channel’s row as before. The generic JSON envelope adds a policy object, { id, title, due_at, due_label, counts: { required, acked, overdue }, people } (plus days on the deadline and escalation events, cycle: "annual" on a cycle’s request, and superseded_by: { id, title } on a retirement), and the summary a summary object, { week, pct, policies, overdue, lowest: { id, title, pct }, snapshot_sha256, snapshot_period }.

Per-space filtering

Each channel can be limited to specific spaces — tick the ones it should hear about, or leave all unticked for everything. A #engineering channel can subscribe to just the Engineering space while a compliance inbox hears about Policies only.

A compliance event carries the policy’s space, so the same filter applies: a channel ticked for the Engineering space hears about Engineering’s policies only. A channel with no filter hears about every policy, private spaces included, exactly as it does for Document published; give a channel that everyone can read a space filter if any policy lives in a private space. The weekly Compliance summary goes only to channels with no space filter, since it covers the whole programme. A deadline is not used up while every subscribed channel is filtered to other spaces: a channel added later for the policy’s space still hears a deadline that is still ahead.

Email (SMTP)

The Email (SMTP) section at the bottom of the page configures the relay used by email channels:

• Host, port, encryption (STARTTLS or implicit TLS), username, and password (write-only, like webhook URLs).
• From address — what recipients see.
• Send test email — verifies the relay end-to-end before you rely on it.

Any standard relay works: Microsoft 365, Google Workspace, Amazon SES, Postmark, Mailgun, or self-hosted. CompassDocs sends plain, skimmable messages — subject line carrying the event and title, body with the actor, space, note, and a link.

Ask in chat (Slack & Teams)

The Ask in chat section lets people question the knowledge base from Slack or Microsoft Teams and get the same grounded, cited answers as in-app Ask — with source links back to the documents.

What chat can see

Chat answers draw only from published documents in non-private spaces. Anyone in the channel can see the answer, so private-space content is never included, no matter who asks.

Slack (slash command):

1. Create a Slack app with a slash command (e.g. /askdocs) whose request URL is https://your-domain/api/integrations/slack/ask.
2. Copy the app’s Signing Secret into the panel, save, and enable.
3. In any channel: /askdocs how do we roll back a deploy? — the answer posts in-channel with cited sources.

Teams (outgoing webhook):

1. In a team: Manage team → Apps → Create an outgoing webhook, callback URL https://your-domain/api/integrations/teams/ask.
2. Copy the security token Teams shows on creation into the panel, save, and enable.
3. In a channel, @mention the webhook: @CompassDocs what's our refund policy?

Requests are authenticated with Slack request signing (with replay protection) and Teams HMAC; the secrets are stored encrypted like every other credential, and both endpoints stay disabled (404) until a secret is saved and the switch is on.

The notification inbox (the bell)

Every user has a personal notification inbox behind the bell in the sidebar — no configuration required, and it works even without SMTP. The bell shows an unread badge and collects, with a deep link each:

• @mentions and new comments on threads they’ve participated in
• Publishes and updates in spaces they subscribe to
• Change requests — approvers see new submissions; authors see approvals and declines (with the reviewer’s note)
• Content reviews coming due (approvers)
• Read-confirmation notices (enterprise) — a request to read and confirm a policy, a reminder, or a re-confirmation notice after a policy you had confirmed changed; each opens the document at its confirmation card
• Training assignments and due reminders (enterprise) — see Training & onboarding
• Helpdesk notices (enterprise, 1.19.0): your requests received, answered, waiting on you and solved, and approvals waiting for you, each opening the request in Get help. Agents’ ticket notices go to the desk’s own bell (see Your desk notifications).

Items mark themselves read on click, or all at once with Mark all read; read items are pruned after 90 days. The bell shows the latest thirty; See all notifications at the bottom of the panel opens the full inbox page (/notifications), which loads older items on demand, and Preferences beside it jumps to the routing grid described below.

Personal chat webhook. Under your name → Notifications each user can paste a Slack or Teams incoming-webhook URL — their notifications are then also posted there (a personal DM channel works well). Only https:// URLs are accepted, and delivery goes through the same SSRF-safe fetch layer as every other outbound call.

Per-event routing. From 1.19.0 the same page holds the full matrix of events and channels described in Your own notifications. Before 1.19.0 it was a smaller “What reaches you where” grid of the same idea.

Read-confirmation notices are also recorded per person (date, kind, policy, who asked, channels used) on the compliance record, kept as long as the record itself; turning the email off here is shown there as “email opted out”, and the in-app notice still arrives. The master email switch does not apply to them (see the deliberate exception).

Notification policies

From 1.19.0 the workspace decides, event by event, what people get and what they may change. Settings → Notifications → Policies (the View notification policies and Change notification policies permissions, notification.policy_read and notification.policy_manage; the Administrator role holds both) lists every event CompassDocs notifies about, in sections. Someone with only View notification policies sees the page read-only.

Section	Events
Read confirmations (enterprise)	Read confirmation requests, Policy reminders, Compliance escalations
Documents and comments	Mentions, Comment replies, Subscribed spaces, Change requests, Review decisions, Review reminders, Weekly digest, Service status
Helpdesk requests (enterprise)	Request received, Reply from the desk, Waiting on you, Solved and satisfaction, Workflow messages, Copied on a request (1.19.1, bell and chat only), Requests joined (1.19.1), Major incident updates (1.19.2, bell and email, never held for a digest)
Approvals (enterprise)	Approval needed, Approval decided
Helpdesk (agents) (enterprise)	The desk’s ticket events (from 1.19.2 including A service your team uses is down, bell and push; from 1.19.4 Shared with you), Report digests, Import checks (1.19.2, bell only) and Webhook turned off (1.19.4, bell only)
Training (enterprise)	Training assigned, Training due, Team digest
Newsletter and announcements	Newsletters, Announcements by email, Newsletter reviews
Security	Password and two-factor changes, New sign-in alerts

Sections for features your license doesn’t include are left off.

Three events are new in 1.19.2:

• Major incident updates (Helpdesk requests): the desk’s updates on a major incident a person’s request is part of, or that they said affects them. One email and bell per person per update, never held for a digest.
• A service your team uses is down (Helpdesk agents): a Status page service a team follows degrades or goes down, and when it is back. Bell and push are on by default; there is no email. An agent it reaches doesn’t also get the Service status bell for that service.
• Import checks (Helpdesk agents): a ticket import’s dry run is ready or failed, to the person who started it. Bell only.

Two events are new in 1.19.4:

• Shared with you (Helpdesk agents): another agent shares a ticket with you, with their message. Bell, email and push are on by default.
• Webhook turned off (Helpdesk agents): an outgoing helpdesk webhook failed for 24 hours and turned itself off, to the desk’s admins. Bell only.

For each event and each channel it can use (bell, email, push for the desk, chat for a personal webhook), the policy sets:

• the default (on or off), and
• who decides: Person chooses (the default: people may change it), Locked on (everyone gets it) or Locked off (nobody does).

and, per section, the email delivery: instant, hourly or daily (see Email digests), locked or left to each person.

Only what you change is stored: everything else follows CompassDocs’s defaults, so a later release’s new event arrives with its own default. Every save is in the audit log (notification.policy_updated, with the events changed).

Security notices are locked on. The Security events (password and two-factor changes, new sign-in alerts) are locked on for email in the catalog and show as locked everywhere, ready for when CompassDocs sends them; nobody can turn them off.

How a notice is decided. In order: security notices always go; then a locked policy wins; then the person’s own choice, or the default; then a pause; then quiet hours; then the digest. The bell is never paused.

Your own notifications

Account → Notifications is each person’s matrix of the same events and channels, in the same sections, from 1.19.0:

• Per event, per channel: switch each on or off. A choice the workspace locked shows Set by your workspace and can’t be changed.
• Email frequency per section: instant, hourly or daily, unless the workspace locked it.
• Quiet hours: hours when email and push wait (the bell still collects).
• Pause everything except security: for 1 hour, until tomorrow, for a week, or until you resume. Security notices still go, and the bell still collects.
• Personal chat webhook and subscriptions, as before.

Your choices from before 1.19.0 carry over unchanged. They are also written to where 1.18 kept them, so rolling back keeps them too.

Agents also have the desk’s own Notifications page for ticket events (see Your desk notifications). When either page turns an event off, it is off.

A few notices are never held by a pause, quiet hours or a digest: read confirmation requests, newsletters, announcements and the weekly digest.

If a person’s preferences can’t be read (a database hiccup), only compliance and security mail is sent to them until they can.

Email digests

With hourly or daily delivery, a person’s notices for that section are gathered into one email instead of one each: hourly on the hour, daily at 08:00 in the person’s time zone. A digest also waits for an agent’s desk quiet hours. Links in it are absolute, so they work from any mail client. Sending is shared safely between app instances, so nobody gets two; a send the mail server refused is tried again the same day. Notices that are never held (above) go instantly whatever the setting.

Personal subscriptions

Workspace channels (above) alert a team; subscriptions alert a person. Every space page has a Subscribe button — subscribers get an email when a document in that space is published or updated (however the change arrives: direct edit, approved change request, or the Claude connector).

• Emails only go to people who can see the space; the person who made the change is never emailed about their own edit.
• From 1.18.0 a handbook-only document is news only to subscribers who may write in its space; other subscribers get no email or inbox notice about it.
• Each user manages their subscriptions (and a master email switch) under your name → Notifications.
• Admins can subscribe a group to a space (Settings → Spaces → Email subscriptions): every member is subscribed automatically, membership changes flow through (including Entra-synced groups), and individuals can mute it without leaving the group.
• Requires SMTP to be configured.

Mention emails work the same way: when someone @mentions a user in a document comment, that user gets an email with the comment and a link to the document — governed by the same master email switch, and requiring SMTP. (The inbox notification appears even without SMTP.)

Email templates

Every alert email CompassDocs sends is a template you can edit — Settings → Notifications → Email templates.

Templates in parts (1.19.0)

From 1.19.0 every email is built from four parts, each from its own library:

Part	What it is	Built-ins
Header	The top of the email: a logo, the workspace name	Standard header (the logo and the workspace name over an accent bar; the default) and No header
Body	What the email says, and its subject line. Each email has its own.	One per email, with CompassDocs’s wording or your edits
Signature	Who the email is from	No signature (the default) and Team signature (“IT · Acme”)
Footer	The last lines: who sent it and how to change notifications	Standard footer (“Sent by Acme · Manage your notifications”; the default) and No footer

The page has five tabs: Templates (every email, grouped by area: Documents, Read confirmation, Training, Helpdesk, Directory, Account and security, Newsletter, Other) and the four libraries, Headers, Bodies, Signatures and Footers.

• Open an email to choose one of each part for it. The first choice, Use workspace default, follows the library’s default, so changing the default changes every email that follows it.
• Each library has one default (bodies aside). Make a part the default from its library.
• Add your own headers, signatures and footers (a holiday banner, a signature with a phone number). A part in use names the emails that use it (“Used by 4 templates”). Built-ins can be edited and Reset to original, but not deleted.
• The preview shows the whole email, all four parts, with sample values, at Desktop or Phone width; Send me a test mails the combination on screen, saved or not, to you.
• Parts are Markdown (bold, links, quotes), with Insert tag in the editor’s toolbar.

Tags in every part: {{org_name}}, {{workspace_url}}, {{accent}}, {{logo}} (the workspace logo as an image), {{recipient_name}} and {{manage_notifications_url}} (the link to the recipient’s Account → Notifications). Signatures also have {{sender_name}}, {{sender_title}} (from the directory) and {{team_name}}. A body has its email’s own tags (the table below).

The Manage your notifications link in the Standard footer opens the email’s own section of the recipient’s notification settings. It is left out of mail to people without an account (such as outside requesters), and of emails that already carry their own link (Document published / updated and Comment @mention) or go to a channel rather than a person (Workflow event).

Built for mail clients. Branded emails use a 600px table layout with inline styles, readable in dark mode, and every email has a plain-text version that joins the parts with blank lines.

Your emails gain a header and footer on upgrade

From 1.19.0 the Standard header and Standard footer are the defaults, so every email gains them on upgrade, unless an admin had already chosen a default header or footer. The body of each email stays word for word what it was. To keep emails as they were, make No header and No footer the defaults.

Emails that carry their own layout, newsletters, the weekly digest and the directory sync report, never use these parts and are unchanged.

Your existing edits carry over. A template you customised before 1.19.0 becomes that email’s body, subject and all.

Helpdesk teams can have their own version of any helpdesk email (a team header or signature, a different footer): open the email and choose A team. Anything a team does not set uses the workspace’s choice. Helpdesk admins, and people with the desk capability Email templates, edit helpdesk emails and their team versions from Desk settings → Email templates too. Deleting a team removes its versions.

The emails

Template	Sent when
Document published / updated	A doc changes in a space someone subscribes to
Announcement	An announcement is posted with email delivery on
Comment @mention	Someone @mentions a user in a document comment
Read confirmation request	Every read-confirmation notice a person asks for: a manager asks people to read and confirm a policy, reminds them, asks one person or everyone again, or a policy they had confirmed changed or came round for its annual re-confirmation. {{request_label}} is Action required, Reminder, Updated or Annual re-confirmation; {{request_type}} completes “{{requester_name}} … that you read and confirm” (requested, sent a reminder, changed the document and asks again, asks again); {{change_note}} and {{reason}} are blank when they do not apply. From 1.13.0 the due tags are filled from each recipient’s own assignment row and blank for a person with no due date: {{due_date}} (the confirm-by date), {{due_line}} (the sentence “Please confirm by 29 Oct 2026.”), {{due_suffix}} (“ by 29 Oct 2026“, which the default subject ends with) and {{days_left}} (whole days until the due date, 0 once it has passed). Default subject: [{{org_name}}] {{request_label}}: confirm "{{doc_title}}"{{due_suffix}}; the default body carries {{due_line}} on its own line, which disappears when blank. From 1.18.3 {{handbook_line}} (“It’s in Employee Handbook.”) and {{handbook_title}} name the handbook for someone asked only through one, and are blank for everyone who can open the policy’s space.
Welcome: policies to read	Sent once to a new account that is enrolled in more than one policy (1.13.0), listing every policy they must read and confirm with its due date, instead of one request per policy (see New joiners and directory groups). Tags: {{count}}, {{policy_list}} (one policy per line, plain text), {{portal_url}} (My policies), {{org_name}}. Default subject: [{{org_name}}] Welcome: {{count}} policies to read
Read confirmation due reminder	The hourly sweep’s automatic reminder (1.13.0): a policy someone must confirm is due soon or overdue, on the policy’s reminder cadence (see Reminders and escalation). Tags: {{doc_title}}, {{doc_url}}, {{due_date}} (blank without a deadline), {{due_line}} (“Please confirm by 29 Oct 2026.”, blank without one), {{status_label}} (Due soon, Overdue or Reminder), {{handbook_line}} and {{handbook_title}} (1.18.3, as above), {{org_name}}. Default subject: [{{org_name}}] {{status_label}}: confirm "{{doc_title}}"
Read confirmation reminders, bundled	Sent instead of several due reminders when one person has more than three policies to confirm in the same hour (1.13.0). Tags: {{count}}, {{policy_list}} (one line per policy with its due date), {{portal_url}} (My policies), {{org_name}}. Default subject: [{{org_name}}] You have {{count}} policies to confirm
Overdue read confirmations, escalation	Sent to a policy’s owner (or whoever switched the requirement on, or the space’s approvers) and to the overdue people’s group leads once someone is past the escalation threshold (1.13.0). Tags: {{policy_title}}, {{overdue_count}}, {{overdue_list}} (one line per person with their due date), {{portal_url}} (the policy in the compliance portal, or the team view for a lead), {{org_name}}. Default subject: [{{org_name}}] {{overdue_count}} overdue on "{{policy_title}}"
Compliance programme report	The scheduled summary of the read confirmation programme (1.14.0), weekly or monthly to the recipients chosen under Compliance › Settings (see Scheduled report). Tags: {{period}}, {{summary}} (the figures, the people overdue, the lowest-compliance policies and the deadlines in the next 14 days), {{snapshot_sha256}} and {{snapshot_label}} (the latest monthly snapshot), {{portal_url}} (Evidence), {{org_name}}.
Training assigned	A training deck or onboarding program is assigned to someone
Training due reminder	A training assignment is due within 3 days or overdue
Team digest (leads)	Weekly, to each group lead (training_team_digest; see Team leads). Tags: {{lead_name}}, {{summary}} (the training lines; blank without the training licence), {{policy_summary}} (the policy lines and the most overdue people, 1.14.0; blank without the read-confirmation licence or while leads do not see policy standing), {{team_url}}, {{org_name}}. Default subject: [{{org_name}}] Your team this week. An override saved before 1.14.0 keeps rendering as it did and must add {{policy_summary}} to show the Policies section.
Helpdesk: request received	A request is received (to the requester; enterprise, 1.19.0). Not sent for automated tickets.
Helpdesk: new reply	An agent replies on a request, or the requester replies (to the agent)
Helpdesk: ticket assigned	A ticket is assigned to an agent
Helpdesk: approval needed	A request waits for someone’s approval, and its reminder
Helpdesk: approval decided	The requester’s request is approved or declined
Helpdesk: workflow task	A workflow opens a task for a team
Helpdesk: request solved	A request is solved, with the satisfaction question when the survey is on
Helpdesk: workflow message	A workflow’s Notify step
Helpdesk: SLA nearing	A reply or resolution target is close (to the assignee or the team’s leads)
Helpdesk: SLA breached	A target has passed
Helpdesk: report digest	A scheduled helpdesk report
Helpdesk: internal note	Another agent adds an internal note to a ticket (to the assignee). It is not a reply thread: an emailed answer is filed as an internal note, never sent to the requester.
Helpdesk: major incident update	The desk posts an update on a major incident: to the requester of every open linked ticket, with the people copied on it, and to people who said “Me too” in Get help (1.19.2)
Helpdesk: requests joined	The desk merges a request into another one (to the requesters of the merged tickets, when the agent chooses to tell them; 1.19.1)
Helpdesk: ticket shared with you	Another agent shares a ticket with an agent, with their message (1.19.4). It is not a reply thread: an emailed answer is filed as an internal note, never sent to the requester.
Helpdesk: customer portal sign-in link	The one-time sign-in link for the customer portal (1.19.1). It has no manage-notifications link: the customer asked for it.
Workflow event	A review/publish/suggestion event fires an email channel

The 1.10.1 default body of Read confirmation request says “read and confirm”, carries the new tags, and ends with “Open the document and confirm at the end that you have read and understood it.” A template you overrode keeps its wording: edit it (or reset it) to adopt the new sentence and tags. The link in {{doc_url}} lands on the confirmation card at the end of the document, on the workspace’s custom domain or, when none is set, the address the request that queued the notice was made to; the notice is queued and delivered within a minute rather than sent while the manager or editor waits (see How notices are sent).

All five read-confirmation templates are sent regardless of a person’s master email switch, because a policy they must read is a requirement, not a courtesy; the per-event email choice under Account → Notifications is honoured (Read confirmations for the request and the welcome, Policy reminders for the two due reminders, Compliance escalations for the escalation), and the compliance record shows “email opted out” for a person who turned it off.

Each body has a subject line and its text, edited in the same rich text editor used for documents. Two things make them dynamic:

• Dynamic tags — placeholders like {{doc_title}}, {{actor_name}}, and {{doc_url}} are replaced with the real values when each email is sent. Use the Insert tag menu in the editor toolbar to drop one at the cursor; each template lists exactly which tags it supports. A tag the template doesn’t know is left visible in the sent email, so typos are easy to spot in the preview rather than silently vanishing.
• Live preview — the pane beside the editor re-renders your draft with realistic sample values as you type, showing the exact subject and styled body recipients will get.

Bodies are markdown, rendered through the same sanitized, brand-accented HTML pipeline as newsletters — links, bold, and quotes work, and a plain-text alternative is generated automatically for text-only mail clients. (Newsletters themselves keep their own editor and are not part of this list.)

Reset to original (before 1.19.0, Reset to default) restores the built-in wording for a body at any time, and a Customized badge marks the ones you’ve changed. Untouched templates keep sending exactly the copy CompassDocs has always used. Edits and resets land in the audit log, and from 1.19.0 so do changes to parts and defaults (email_template.*).

Weekly digest

Each user can opt into a weekly digest under Account → Notifications: a Monday-morning email with what changed in their subscribed spaces that week, reviews to handle (approvers and admins), and the week’s most-read documents. Everything is scoped to what the recipient can see, and users with nothing to report get no email. From 1.18.0 the digest’s changes and most-read documents leave out handbook-only documents unless the recipient may write in their space. Requires SMTP; sent once per week regardless of how many app instances run. Group leads get a different weekly email, the Team digest (leads) above, about the people they lead.

Delivery semantics

Alerts are fired in the background with a short timeout — a slow or dead webhook never delays a save, publish, or review action. Failures don’t retry (the next event will try again); the per-channel status shows the last result so problems surface quickly.

Read-confirmation notices are the exception: they go through a queue that the server drains every minute, retried up to three times if the mail server is down, and each one is logged per recipient on the compliance record. See How notices are sent.