Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

09.05 Notifications and Email Preferences

SimpleRisk's notification system runs through the Notification Extra and the cron job — what events trigger emails, which roles receive them, and the candid limitation that there's no per-user opt-out in Core.

Why this matters

Notifications are how SimpleRisk reaches people outside the application. A risk gets submitted; the owner needs to know about it. An audit gets initiated; the assigned tester gets a heads-up. A document review comes due; the document owner gets reminded. Without notifications, the workflows the application supports require everyone to log in and check on cadence — which they won't, which produces queues that age and reviews that slip.

The honest story about notifications in SimpleRisk: they're system-wide, not per-user, in Core. There's no profile-page surface that lets you say "I don't want emails about audit comments" or "send me everything to my secondary address." The notification preferences are admin-controlled at the system level: which event types fire emails, which roles (submitter, owner, manager, team) receive them, what cadence the notification cron runs on. Programs that want per-user opt-out don't get it natively; the workaround patterns (email rules in your inbox, a dedicated SimpleRisk address with its own filters) are downstream of SimpleRisk.

The other thing worth knowing: the notification system is gated by the Notification Extra. Without the Extra activated, SimpleRisk doesn't send notifications even for events that would normally fire them. Programs running on Core-only Notification (not the Extra) don't get email notifications at all; users have to log in and check the dashboards on their own cadence.

The third thing: the cron job is what actually sends the emails. The notification system writes notification intentions to the database (or queues them); the cron_notification.php cron job picks them up and sends them through the configured SMTP server. If the cron isn't running, emails don't go out — the symptom is silence (no notifications), which is harder to notice than a failure that surfaces an error. Programs that depend on notifications need to monitor the cron's health.

Before you start

Have these in hand:

  • A SimpleRisk install with the Notification Extra activated. Without the Extra, no notifications fire. Confirm with your admin or via the Extras page (/admin/extras.php) that the Notification Extra is active.
  • An admin-configured SMTP setup. SimpleRisk needs valid SMTP server settings to send email. The configuration lives in the admin area at /admin/index.php or the Mail tab; settings include host, port, authentication credentials, From Email, Reply To Email. Without working SMTP, the notification cron generates no outbound mail.
  • A clear understanding of which events you expect to receive notifications for. The Notification Extra has many event triggers; receiving (or not receiving) a specific notification depends on which event triggered, your role's relationship to the affected entity, and the system-wide settings.

Step-by-step

1. Confirm the Notification Extra is active

The Notification Extra is what makes notifications happen. Without it, the rest of this article doesn't apply.

To confirm:

  • An admin can navigate to Configure → Extras and check whether Notification Extra appears as activated.
  • Alternatively, the configuration setting notification_extra (or similar) tracks the active state.

If the Extra isn't active, ask your admin to install and activate it. Without it, you won't get email notifications.

2. Understand which events trigger notifications

The Notification Extra fires email notifications on a defined set of events. The events are global (every event of a given type fires for every entity affected) but each event respects role-based routing rules that determine who receives the notification.

Common events:

  • new_risk — a new risk is submitted to the register.
  • risk_update — an existing risk's fields change.
  • new_mitigation — a mitigation is planned for a risk.
  • mitigation_update — a mitigation's fields change.
  • risk_review — a management review is submitted on a risk.
  • risk_close — a risk is closed.
  • risk_comment — a comment is added to a risk.
  • audit_initiate — a control test audit is initiated.
  • audit_comment — a comment is added to an audit.
  • audit_status_change — an audit's status changes.
  • new_document — a new document is added to the document library.
  • document_update — a document's fields change.

Plus auto-notification events that fire on a recurring cadence rather than from a user action:

  • auto_notify_unreviewed_past_due_risks — periodic reminder about risks past their next-review date.
  • auto_notify_planned_mitigations — periodic reminder about open mitigation plans.
  • auto_notify_audits — periodic reminder about scheduled audits.
  • auto_notify_unmitigated_risks — periodic reminder about risks without mitigations.
  • auto_notify_unreviewed_past_due_policy_control_exceptions — periodic reminder about expired exceptions.
  • auto_notify_document_reviews — periodic reminder about document reviews coming due.

Each event has system-wide on/off control through NOTIFY_ON_ settings (e.g., NOTIFY_ON_NEW_RISK, NOTIFY_ON_AUDIT_INITIATE). When the toggle is off for an event type, no notifications fire for that event regardless of role.

3. Understand the role-based routing

For each event that fires, the Notification Extra evaluates which roles should receive the notification. The available roles:

  • NOTIFY_SUBMITTER — the user who originally submitted the affected entity.
  • NOTIFY_OWNER — the user assigned as the entity's owner.
  • NOTIFY_OWNERS_MANAGER — the manager of the entity's owner.
  • NOTIFY_TEAM — all members of the team(s) assigned to the entity.
  • NOTIFY_ADDITIONAL_STAKEHOLDERS — users on the entity's Additional Stakeholders list.

Each role has a system-wide on/off setting; when on, that role receives notifications for events that fire. The settings are global — there's no per-user opt-out and no per-event role configuration.

A practical example: when the system is configured with NOTIFY_OWNER=true and NOTIFY_OWNERS_MANAGER=true, a new-risk event sends emails to both the assigned owner and the owner's manager. To suppress notifications to managers without affecting other roles, the admin disables NOTIFY_OWNERS_MANAGER system-wide; there's no way to disable manager notifications for some managers but not others.

4. The cron schedule controls when notifications go out

The Notification Extra writes notification intents and the cron job processes them. The cron's schedule is configurable through several settings:

  • CRON_PERIOD — the period type (daily, weekly, monthly).
  • CRON_HOUR and CRON_MINUTE — the time of day to run.
  • CRON_DAY_OF_WEEK — for weekly schedules.
  • CRON_DATE and CRON_MONTH — for monthly schedules.
  • CRON_SEND_EMAIL_1 through CRON_SEND_EMAIL_6 — separate auto-notification triggers that can be configured for different cadences.

The cron job is simplerisk/cron/cron_notification.php, run from the system's cron scheduler (Linux cron or systemd timer on the supported host). The admin configures the system cron to invoke the script on the desired cadence.

If the cron isn't running, notifications queue up but don't send. The symptom is "I'm not getting emails I expected" — and the most common cause is that the system cron stopped running (server reboot, cron config change, file-system permission issue).

5. The user-facing options for managing notifications

In Core SimpleRisk, the user-facing options are limited:

  • Update your email address. The email SimpleRisk sends to is the email on your user record. Updates to the email require an admin (the profile page shows the email read-only — see Your Account and Profile).
  • Assign yourself out of the relevant roles. If you're getting too many manager notifications, removing yourself as the manager on specific risks (with admin help if needed) reduces the volume. This isn't really a notification setting — it's a workflow change — but it's the operational lever that exists.
  • Use email rules client-side. The most common workaround for unwanted notifications is rules in your email client that filter SimpleRisk emails to a folder, mark certain types as low-priority, or auto-archive specific event types. These are downstream of SimpleRisk and don't require any SimpleRisk changes.

6. For programs that need richer notifications: the Notification Extra's templates

The Notification Extra ships email templates that the admin can customize. Templates include:

  • New-risk submission templates.
  • Mitigation-update templates.
  • Audit-initiation templates.
  • Auto-notification (reminder) templates.

Each template is editable through the Notification Extra's configuration surface (typically under Configure → Notification or similar). Customizations include the email subject, the body content, and the placeholder substitutions for entity-specific values.

Programs needing branded notifications (organization name, custom signatures, custom branding) edit the templates rather than the application's behavior. The customization is admin-side; users don't see template editors.

7. For programs that need more than the Notification Extra provides

The Notification Extra covers the standard SimpleRisk notification needs. Programs needing more (per-user opt-out, multi-channel notifications like Slack/Teams, custom event triggers, complex routing rules) have a few options:

  • The Workflows Extra — adds custom workflow automation that can trigger custom email sends with custom conditions. See Understanding SimpleRisk Workflows for the full picture.
  • External webhook integration — for non-email channels, a custom integration that listens for SimpleRisk events (via the v2 API or via direct database polling) and forwards to Slack/Teams/PagerDuty.
  • Custom development — for substantially custom routing logic, custom code added to the Notification Extra or as a separate Extra.

The built-in scope is deliberately conservative; the customization paths exist for programs that genuinely need more.

Common pitfalls

A handful of patterns recur with notifications.

  • Expecting per-user opt-out in Core. This is the most common surprise. SimpleRisk doesn't ship a notification preferences page on the user profile. The notification settings are global, set by admin, and apply to all users with the relevant role on the relevant entity. If you don't want notifications, your options are inbox rules or workflow changes, not in-application settings.

  • Cron not running silently. Notifications stop firing when the cron stops running. The symptom is "I haven't gotten any SimpleRisk emails this week" — which can look like good news but isn't. Periodically confirm the cron is healthy (check the cron log, send a test action that should trigger a notification, look for the resulting email).

  • SMTP misconfiguration causing silent drops. Even with the cron running and the Extra active, bad SMTP settings (wrong host, wrong port, wrong credentials, blocked outbound port 25/587) cause emails to fail send without surfacing in the UI. The email server's own logs are the diagnostic surface; the SimpleRisk side just sees "tried to send, failed."

  • Forgetting to add the recipient address to the SPF record. When SimpleRisk sends from your-domain@example.com but isn't authorized in the SPF record for example.com, downstream mail servers may bounce or quarantine the messages. Coordinate with whoever owns DNS for the From-address domain to add SimpleRisk's sending IP to the SPF record. The same applies to DKIM and DMARC if your organization has them.

  • Activating the Extra without configuring SMTP first. Activating the Extra and then having users wonder why no emails arrive (when the SMTP settings are blank) is a common rollout mistake. Configure SMTP before activating the Extra (or before announcing notifications to users).

  • Treating notifications as the only signal. A program that depends on notifications for everything (no one logs in to check the dashboards because they trust the emails) breaks the moment the cron has a hiccup or an SMTP issue. Notifications are one signal; the dashboards remain the source of truth. Build operational habits that don't require notifications to stay current.

  • Email rules that silently swallow important notifications. A user who set up an email rule to auto-archive SimpleRisk notifications during a noisy week may never see the high-priority audit-finding notification two months later. Periodically review email rules; ensure the important categories aren't being suppressed unintentionally.

  • Customizing templates without testing. Editing notification templates without sending a test notification afterward can introduce broken placeholder substitutions, broken HTML, or broken plaintext alternatives. After any template edit, trigger a test event (submit a test risk, initiate a test audit) and verify the resulting email looks right before turning the template loose on real notifications.

  • Auto-notifications timing collision with batch operations. A bulk import that creates 50 risks in two minutes, with NOTIFY_ON_NEW_RISK enabled, fires 50 separate emails to the configured recipients. The recipients receive an inbox flood. For large imports, either temporarily disable the relevant notification toggle, run the import outside business hours, or coordinate with recipients in advance.

Related