Notifications
A notification tells someone that something happened: a period was closed, a nightly job failed, a schedule was missed. Rules decide when; channels decide how — the bell in the application, an e-mail, or a call to a connector.
At a glance
What users see
- The bell in the header shows the number of unread notifications, updated live. Its menu lists the latest six; Mark all read and View all are at the bottom. Clicking a notification marks it read and opens its link.
- The Notifications page (from View all) lists them with All / Unread tabs and Mark all read.
Each user sees only their own notifications.
The e-mail account
E-mail goes through the SMTP server set in Liberty Next → Administer → App → Notifications (email):
| Field | Default | Notes |
|---|---|---|
| Notifications enabled | on | Off: no rule fires. |
| SMTP host, Port | —, 587 | Without a host, only the bell works. |
| Encryption | STARTTLS | STARTTLS (usually port 587), SSL / implicit TLS (usually port 465) or None. Changing it sets the usual port. |
| Timeout (s) | 20 | |
| User, Password | — | The password is encrypted with the install's master key. |
| From address | the user | Falls back to the user name when empty. |
| Keep read notifications (days, 0 = forever) | 90 | Read notifications older than that are purged, at startup and every six hours. Unread ones are kept. |
E-mails are plain text: the subject, then the body, then the rule's link.
Rules
Rules are edited in Liberty Next → Build → Notifications and saved in notifications.toml — a change applies without a restart. Send a test sends the rule being edited, even unsaved, with sample values to its recipients.
Triggers
| Trigger | Fires when | Settings |
|---|---|---|
| A screen event | A row is inserted, updated or deleted through a screen. | App, Screen, Events (insert / update / delete), and optionally Only when the written row has: field = value conditions, all required (STATUS = closed). |
| A job event | A Nomaflow run ends. | Jobs — several picked in one list, empty = every job — and Events: failure, succeeded, canceled, missed (a schedule that did not run — see Schedules), long_run with a threshold in minutes, late (no successful run by the job's Must have succeeded by deadline). |
| A screen action | A screen action of type send_notification runs (a button or a step of an action chain). | Nothing more: the screen action names the rule and passes the row's values. |
long_run is checked when the run ends: it reports a run that lasted at least the threshold, not a run still in progress.
Channels
| Channel | Delivers |
|---|---|
portal | A notification in the bell of each recipient user. |
email | An e-mail to each recipient that has an address. |
action | Runs a query (SQL connector) or calls an endpoint (API connector) with the message's values — to post to Teams or a webhook, or to write a log table. Its parameters are the event's values plus SUBJECT, BODY and RULE. |
A channel that fails is logged and does not stop the others. Sending runs in the background: a save or a job never waits for the mail server.
Recipients
| Form | Means |
|---|---|
user:alice | That user. |
role:controllers | Every active user holding the role. |
email:finance@example.com | An address — e-mail only. |
In the editor, pick users and roles from the list or type an address. An entry without a prefix is sent to as an address when it contains @; any other is ignored and logged.
Placeholders
Subject, body and link take {NAME} placeholders, written in any case:
| Trigger | Placeholders |
|---|---|
| Screen event | Every column of the written row, plus USER, APP, SCREEN, EVENT. |
| Job event | JOB, RUN_ID, STATE, ERROR, DURATION_MINUTES, ROWS, and EXPECTED_AT for a missed schedule or a deadline. |
| Screen action | The values passed by the action, plus USER. |
An unknown placeholder is left as written. In the editor, the button beside the subject, the body and the link lists the placeholders of the trigger and inserts the one picked where the cursor is; the same button sits beside the subject and the body of a notify step.
In TOML
[notifications.period_closed]
label = "Period closed"
trigger = { kind = "screen", app = "sales", screen = "period_status", events = ["update"], when = [{ field = "STATUS", value = "closed" }] }
channels = ["portal", "email"]
recipients = ["role:controllers", "email:finance@example.com"]
subject = "Period {PERIOD} closed by {USER}"
body = "Company {COMPANY}: the period is now read-only."
link = "/screen/sales/period_status"
[notifications.job_failed]
trigger = { kind = "job", events = ["failure", "missed"] }
channels = ["email"]
recipients = ["role:ops"]
subject = "{JOB}: {STATE}"
body = "{ERROR}"
From a job step
A job can also send a message itself, as one of its steps, with the files it produced attached — a scheduled digest. See Steps → Notify.
A job's own alerts
A job can also warn on failure without a rule, from the Alerts block of the job editor:
[jobs.alerts]
on_failure = true
recipients = ["role:ops", "user:alice"]
On failure, each recipient gets a notification Job <id> failed with the error, in the bell and by e-mail. With Warn if a run exceeds (minutes) (on_long_run_minutes), a run that lasts at least that long also sends Job <id> ran N min (threshold T), whether it failed or not. Write recipients as user:, role: or email: — an entry without a prefix is taken as an e-mail address.
Tips
- Start with one rule:
failureandmissedon every job, to the operations role. - Prefer roles to named users: the rule follows team changes.
- Use Send a test after changing the SMTP account.
- Keep the bell for what needs action; send the rest by e-mail to a shared box.