Notifications & broadcasts

Notifications keep the right people informed automatically: when a record is created, a workflow step fires, or someone is @-mentioned, a rule you configured sends a message — by email, the in-app bell, mobile push, or any combination. Everything lives in Admin → Notifications.

Notification rules

A rule says on this event, for these records, tell these people this message. Create one under Rules:

1. Pick the record type and the trigger: record created / updated / deleted, a specific workflow transition, an @-mention, or a new comment (optionally scoped to one comment stream).
2. Narrow it with a condition (the standard filter editor) and, for updates, the watched fields that must have changed.
3. Choose the recipients — as many rows as you like, each To, Cc or Bcc:
   • A field on the record — an email field, or a user field (“the assignee”).
   • A related record — follow a relationship and use the linked person’s email.
   • A group — all its members.
   • A fixed email address.
4. Write the subject and message, choose the channels, and save.

Merge fields

Messages are templates: insert any field of the record with {{firstName}}, plus built-ins like {{ref}} (the record ID), {{label}}, {{link}} (a direct link to the record) and {{recipient.name}}. Comment-triggered rules can include {{comment}} and {{comment.author}}. The editor’s merge-field picker lists everything available — dates and user fields arrive already formatted as readable text.

The recipient’s own record

When a rule is delivered individually and its recipients come from a query, a field or a relationship, each mail knows which record the recipient is — so {{recipient.<field>}} merges that person’s own data: {{recipient.firstName}}, {{recipient.address.city}}. The picker lists them as “Recipient · …” once a query recipient’s type is chosen.

Content stored on the record

A rule’s message can be as small as {{body}}: the real content then lives in a field of the record — the natural shape for a newsletter whose HTML is written on a Campaign record and reviewed there. Merge fields written inside that field’s content are resolved too, including the recipient ones: a campaign body containing Dear {{recipient.firstName}} and an unsubscribe footer with {{recipient.portalLink.subscription}} renders per recipient exactly as if it had been typed in the rule. One level of nesting is resolved.

Portal links minted at send time

{{recipient.portalLink.<portal-slug>}} renders a personal no-login link to any of your portals for the recipient’s record — a fresh, private, expiring link is created for each person while the mail is built. Nothing to pre-generate, nothing stored on the record. This is the classic newsletter footer:

<p><a href="{{recipient.portalLink.unsubscribe}}">Manage my subscription</a></p>

{{portalLink.<slug>}} (without recipient.) does the same for the triggering record — useful in a rule on the person’s own type, e.g. a confirmation mail. The picker offers one entry per active portal. A link renders empty when the portal is inactive, the Portals add-on is off, or the recipient isn’t of the portal’s type — the mail still goes out. The link’s lifetime is the portal’s link expiry (30 days by default; set linkTtlDays in the portal’s config to change it). Personal links only make sense for individual delivery: a collective mail renders them empty.

Unsubscribe header

The rule’s Unsubscribe header (List-Unsubscribe) field takes a link template — typically the same portal-link merge field. It is sent as the standard List-Unsubscribe mail header, which Gmail, Outlook and Apple Mail surface as a native Unsubscribe button next to the sender. Requires the SMTP transport; HTTP mail providers don’t carry custom headers.

Tracking link clicks

Turn on Track link clicks on a rule or a broadcast and every link in the message is routed through PeoplePit: the reader lands on the real page a few milliseconds later, and the click is recorded — which message, which link, which recipient record, when. Mail-security link scanners that pre-fetch links are recognised and kept out of the counts.

What you see:

• The Sent log gains a Clicks column per message.
• Any record that triggered a rule shows a Messages section on its detail page, with the messages sent about it and, per message, which links were clicked, by whom and when.

What you can do with it is configuration, not a feature of any particular use case: a click raises the Orchestrator trigger “A link in a sent message is clicked” on the record the message was about, with the recipient record, the link and the message in the run context. Typical flows: create a Reacted to relationship between the recipient and the record (then “people who reacted to X” is an ordinary relationship filter everywhere), stamp a last engaged date on the recipient, or move the recipient through a workflow. The trigger can be narrowed to one rule, to links whose URL contains some text, or to the first click only.

Tracked links point at the deployment’s public API URL (API_PUBLIC_URL) when it is configured — a plain, instant redirect. Otherwise they point at the workspace’s App base URL (Settings), where the app forwards the visitor to the API; make sure that setting is a real https:// address of your workspace.

Three delivery channels

Each rule chooses its channels independently:

• Email — sent through your configured mail delivery.
• In-app bell — appears in the recipient’s bell in the top bar; clicking it opens the record (or another record, or nothing — configurable per rule).
• Mobile push — mirrors the bell to the PeoplePit mobile app, when the Mobile push add-on is enabled.

A quiet FYI can be bell-only; an urgent alert can be all three. Delivery can be immediate or batched into a daily digest, and sent individually per recipient or as one collective message.

Templates

Reusable email templates hold your standard layout and wording — build them once with the rich editor (formatting, images, merge fields), reference them from rules, and update them in one place.

Broadcasts

Broadcasts are messages not tied to a record event — announcements and newsletters. Under Broadcasts:

1. Write the message (same editor; {{recipient.name}}, {{recipient.email}}, the recipient’s own fields {{recipient.<field>}} and send-time portal links {{recipient.portalLink.<portal>}} are all available).
2. Choose recipients: groups, fixed emails, or — most powerfully — a filtered query over any record type with an email field: “all subscribed people in campaign X” is just a filter.
3. Pick the channels — and optionally the Unsubscribe header template — then either Send now or set a schedule — once at a date and time, or recurring: every day at 9, every Tuesday and Thursday, every 2 weeks, hourly.

A newsletter with one-click unsubscribe is therefore: a portal over your people type with an “Unsubscribe” action, a broadcast (or a rule on a campaign record) whose footer contains {{recipient.portalLink.<that portal>}}, and the same merge field in the Unsubscribe header.

The sent log

Sent log shows every message: queued, sent, or failed, with the reason. Retry failures, cancel queued messages, and send yourself a test before a big broadcast goes out.

Email delivery settings

Under Settings, configure how email leaves your workspace — your SMTP server or an HTTP mail service — plus the sender address, the base link used by {{link}}, and how long read bell notifications are kept. Send a test message to confirm delivery before enabling rules; a failed test shows the provider’s own reason (authentication rejected, connection timeout, …).

SMTP blocked by your host? Many cloud platforms drop outbound SMTP connections — the symptom is a test that fails with “Greeting never received” or a connection timeout even though the same credentials work elsewhere. Switch the provider to HTTP API and pick a service: Brevo, SendGrid, Resend, Postmark, or ZeptoMail (Zoho) — Zoho’s transactional mail API, the HTTPS route for Zoho Mail users (create a Mail Agent in ZeptoMail, verify your domain there, paste its Send Mail token as the API key; EU accounts pick the EU variant). Custom takes any JSON mail API. HTTP providers carry the From, recipients, subject and HTML body; threading headers, attachments and the List-Unsubscribe header need SMTP.