Communication & Channels
Notifications
Create notification templates and control in-app, email, and channel delivery.
Notifications
Notifications covers notification templates, in-app alerts, email delivery, browser notifications, realtime events, and user messaging preferences. Use this page when you are setting up the product surface, reviewing a rollout, or troubleshooting why users see a different result from an administrator.
What this surface is
- Primary purpose: notification templates, in-app alerts, email delivery, browser notifications, realtime events, and user messaging preferences.
- Where users start: Templates live at
/settings/application/notification-templates; individual template studio pages use/settings/application/notification-templates/:templateId. - Where administrators configure it: Email and browser notification defaults are in company settings; personal preferences live in user profile settings.
- Runtime/detail surface: Notifications are triggered by tasks, tickets, workflows, approvals, billing, documents, integrations, and system events.
- Platform connections: Notifications connect SMTP settings, template merge fields, realtime streams, browser permissions, and workflow side effects.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Templates live at /settings/application/notification-templates; individual template studio pages use /settings/application/notification-templates/:templateId. | Day-to-day work and review. |
| Configuration | Email and browser notification defaults are in company settings; personal preferences live in user profile settings. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | Notifications are triggered by tasks, tickets, workflows, approvals, billing, documents, integrations, and system events. | Testing the live experience users actually see. |
Configure it
- Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
- Open the owning product route: Templates live at
/settings/application/notification-templates; individual template studio pages use/settings/application/notification-templates/:templateId. - Review the configuration route and permissions before changing live behaviour: Email and browser notification defaults are in company settings; personal preferences live in user profile settings.
- Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Template list, Template studio, and Email first because they shape the rest of the rollout.
- Add In-app and Browser only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: Notifications are triggered by tasks, tickets, workflows, approvals, billing, documents, integrations, and system events.
- Check downstream connections after saving: Notifications connect SMTP settings, template merge fields, realtime streams, browser permissions, and workflow side effects.
- Record the owner, rollout date, and support path for the configuration.
- Review the first week of activity and remove any option that users do not understand or need.
Configuration options
| Option | Use when | Notes |
|---|---|---|
| Template list | Admins need to edit messages | Route: /settings/application/notification-templates. |
| Template studio | A single template needs content edits | Route: /settings/application/notification-templates/:templateId. |
| Users need off-platform delivery | Requires tenant mail configuration. | |
| In-app | Users are active in Antly | Good for assignments and status changes. |
| Browser | Users need desktop/mobile alerts | Requires browser permission and tenant setting. |
| Realtime | UI should update live | Backed by realtime notification streams. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Template list and Template studio.
- Permissions still matter even when a menu, page, or link is visible.
- If users see empty data, check role filters, enabled apps, ownership rules, and saved filters before editing records.
- If a change affects customers or public visitors, test from a logged-out or customer account as appropriate.
- Use reports or logs to confirm the change produced the expected operational result.
- Capture configuration decisions in rollout notes so support teams know what changed.
- Do not reuse one option for unrelated processes just because it is already configured.
- Review linked notifications, workflows, dashboards, and reports after changing this surface.
- Prefer narrow changes that can be tested with sample data before a tenant-wide rollout.
- When troubleshooting, start at the route users open, then inspect configuration, permissions, and logs in that order.
- Keep retired settings hidden or archived so users do not choose outdated paths.
- Assign an owner for ongoing review; unattended configuration becomes stale quickly.
For developers
Use these pages when the surface is read or changed by code, scripts, embeds, widgets, API clients, webhooks, or realtime listeners.