Docs
⌘K

#Notifications

When a decision needs a human, Ratifia tells the right people it's waiting. The guiding principle is pointer, not payload: by default a notification carries only enough to say "you have an approval, here's what it's about, here's how urgent, come act on it." The case itself (the prompt, context, AI output, drafts, payload) lives behind sign-in in Ratifia.

Notifying is not deciding. A notification is just getting someone's attention. A plain yes/no can be answered right in it; anything more opens the app (see where people answer). Even with no notification configured, the decision still waits safely in the Inbox.

#Pointer, not payload

By default, every notification (email, Slack, Discord, push) renders from a single summary. It contains only:

  • the workflow / step the decision belongs to,
  • the engine,
  • a humanized SLA ("expires in 22m", "overdue", "no expiry"), and
  • a deep link back into Ratifia, where the reviewer signs in to see the full detail.

Email adds three things so the reviewer can tell what they're being asked: the org name, the exact deadline in UTC, and the decision's headline (its context.title, or the start of its prompt when there's no title, trimmed to about 140 characters). The headline is the one piece of case content that leaves Ratifia by default, so keep PHI and PII out of decision titles and put sensitive detail in context, which stays behind sign-in. Better still, link to it rather than copying it: see Sensitive data and PII.

The notification is a doorbell: the case itself only opens once the reviewer is authenticated in Ratifia.

#How much a notification carries

The amount of detail is a per-org setting, not a per-caller choice:

  • Reference (default). The summary described above.
  • Rich. The decision's context is embedded directly in the notification, for teams that accept content leaving the boundary in exchange for at-a-glance review. Ratifia enables this per org on request; there is no self-serve toggle.

The default is reference mode, and any failure to resolve the setting degrades back to reference, so Ratifia never falls open to leaking content on an error.

Content mode is org-wide

Because the setting is per org, the calling code doesn't decide how much a notification reveals. A security posture is set once, centrally, rather than trusted to every worker that requests a decision.

#How a person is reached

When a decision is raised, everyone in its approver group is told at once:

  • Email. One email per approver, delivered through the outbox, so a send is retried rather than lost. A plain yes/no carries one-click Approve / Reject links; anything more carries a link to the app.
  • Slack or Discord. When your org has connected them, every decision is posted to the org's channel and approvers with a verified Slack or Discord identity are @-mentioned. A plain yes/no gets Approve / Reject buttons, and in Slack so does a draft of up to 1,500 characters on rich orgs (see Drafts); anything more gets an Open in Ratifia button. When the decision ends, the message is updated with the outcome and its buttons are removed.
  • Push. Anyone who has registered the mobile app gets an inbox notification. Registering a device is the opt-in; a person can revoke their devices.

The one timed follow-up is the SLA reminder, emailed once to the decision's assignee as the deadline nears. A deactivated member is not notified at all.