Appearance
Notifications
Where to find it: the notification bell in the application header, and Work & Decisions, then Alerts Center (/alerts).
Notifications tell people something has happened. They do not, by themselves, create an obligation.
The three-way distinction
| Event | Notification | Workbench task | |
|---|---|---|---|
| Means | Something happened | Someone may need to know | OrviQ is waiting for a specific person |
| Example | A collector run finished | An indicator moved to failing | A mapping needs your approval |
| Requires action | No | Optional | Yes |
| Blocks a chain | No | No | Yes |
| Appears in the Workbench | No | No | Yes |
A notification is a nudge. A task is an obligation. Conflating them produces either a Workbench full of noise or a notification stream people learn to ignore.
What generates a notification
| Category | Examples |
|---|---|
| Assignment | An ownership offer, an assigned obligation, a delegated item |
| Governance | A submission for your review, an approval decision on your submission, a return |
| State change | A finding assigned to you, an action plan approved, an exception approved or rejected |
| Deadline | An approaching or passed due date, driven by SLA policy |
| Alert policy | A configured condition matching |
Every governed workflow stage that creates a Workbench task also dispatches a notification. The task is the obligation; the notification is how you find out about it.
Alert policies
Alert policies define conditions that generate alerts, and who receives them.
They are used for the operational signals that are not workflow stages: an engagement review falling due, a contract expiring, a threshold being crossed.
| Element | Purpose |
|---|---|
| Trigger | The condition |
| Recipients | Who is alerted |
| Schedule | When the sweep evaluates |
Deduplication is built in: one active event per policy, source, trigger and recipient. A condition that stays true for six weeks produces one alert, not forty-two.
Configured under Administration, requires settings.manage.
The Alerts Center
The Alerts Center shows active alerts, their source, when they fired and their state. Use it to see what the alerting layer is currently saying, and to identify policies that are firing constantly — which usually means a threshold set at a level the organisation routinely operates beyond.
Delivery
Notifications are delivered in the application through the bell. Where notification providers are configured, they can also be delivered by email and other channels.
Provider configuration is under Administration and requires settings.manage. See Notification Providers.
In-application delivery is the source of truth
Workbench tasks appear regardless of whether external delivery succeeded. If an email provider is misconfigured, people still see their obligations when they open the platform.
Do not rely on external notification for anything governance-critical. Rely on the Workbench.
What does not generate a notification
Automated technical activity: collector runs, indicator evaluations, freshness sweeps, source checks, scheduled recalculations.
These produce events. They generate a notification only where an alert policy is configured to raise one — for example, a policy alerting on a connection moving to error.
Managing notification volume
Fix the source, not the filter. A notification stream people ignore is usually caused by a small number of over-broad alert policies.
Check recipients on alert policies. A policy alerting an entire department about an individual engagement's review date generates volume without accountability.
Watch for constantly firing policies. Deduplication prevents repetition, but a policy where a dozen sources are always in the triggering state produces a permanently populated Alerts Center.
Permissions
| Action | Permission |
|---|---|
| View notifications and alerts | work.read |
| Configure notification providers | settings.manage |
| Configure alert policies | settings.manage |
| Run the alert sweep | settings.manage |
Example
A control owner's notifications over a week.
| Day | Notification | Corresponding task? |
|---|---|---|
| Mon | Ownership of CTL-2026-0044 offered to you | Yes — Awaiting acceptance |
| Mon | Indicator IND-2026-0009 moved to failing | No — informational |
| Tue | Finding FND-2026-0071 assigned to you | Yes — My work |
| Wed | Action plan ACT-2026-0188 approved | No — informational |
| Thu | Engagement ENG-2026-0041 review due in 14 days | No — alert policy |
| Fri | Action plan ACT-2026-0188 returned by the verifier | Yes — Returned to me |
Six notifications, three tasks. The three informational ones are useful context; only three require the owner to do something, and those three are the ones in the Workbench.
What did not generate a notification: 42 collector runs, 84 indicator evaluations and one freshness sweep.
Troubleshooting
"I am not receiving email notifications." Check notification provider configuration under Administration. In-application notifications and Workbench tasks are unaffected.
"I receive too many alerts." Review alert policy recipients and thresholds. Deduplication prevents repetition of the same condition, not breadth of configuration.
"I got a notification but there is no task." It was informational. Not every notification carries an obligation.
"There is a task but I never got a notification." Check external delivery configuration. The task is authoritative regardless.