Appearance
Notification Providers & Alert Policies
Where to find it: Administration, then Notification Providers (/settings/notifications) and Alert Policies (/settings/alert-policies).
Notification providers
Providers are the delivery channels through which notifications reach people outside the application.
| Concept | Meaning |
|---|---|
| Provider | A configured delivery channel |
| Delivery | An attempt to send |
| Log | The record of attempts |
Configuration requires settings.manage.
In-application delivery is the source of truth
Workbench tasks appear regardless of whether external delivery succeeded. If a provider is misconfigured, people still see their obligations when they open the platform.
Never rely on external delivery for anything governance-critical. Rely on the Workbench, and treat external notification as a convenience that reduces the time between something becoming due and someone noticing.
Alert policies
Alert policies define conditions that generate alerts and who receives them. They cover the operational signals that are not workflow stages.
| Element | Purpose |
|---|---|
| Trigger | The condition being watched |
| Recipients | Who is alerted |
| Sweep | When the condition is evaluated |
Example trigger types
| Trigger | Fires when |
|---|---|
engagement_review_due | A third-party engagement review date is approaching |
engagement_review_overdue | A review date has passed |
engagement_contract_expiring | A contract expiry is approaching |
Deduplication
One active event per policy, source, trigger and recipient.
A condition that stays true for six weeks produces one alert, not forty-two. This is the mechanism that keeps an alerting layer usable, and it is built in rather than configured.
Sweeps
The alert sweep evaluates policies and generates events. It is administered under tenant settings and requires settings.manage.
It is deliberately not exposed to module read permissions. A user with tprm.read cannot trigger the alert sweep, because a sweep is an administrative operation with tenant-wide effect.
Entitlement matching runs inside the sweep: a matcher for third-party triggers hard-checks the Third-Party Risk entitlement before returning any engagement, so a tenant without TPRM receives no jobs relating to it.
Alert sweeps are technical schedules
Like collector runs and indicator evaluations, sweeps do not appear on the GRC Calendar. The obligation they alert about does; the evaluation job does not.
Designing alert policies
Alert people who can act. A policy alerting an entire department about one engagement's review date generates volume without accountability. Alert the owner and, at most, their manager.
Set thresholds you would act on. If a fired alert would not change what anyone does, the policy is decoration.
Watch for constantly firing policies. Deduplication prevents repetition of the same condition, but a policy where a dozen sources are always in the triggering state produces a permanently populated Alerts Center that people stop reading.
Prefer specific triggers to broad ones. engagement_contract_expiring on material engagements is actionable. The same trigger across every engagement is noise for the 80% that are low criticality.
Notification, event and task
The distinction matters when configuring policies.
| Event | Notification | Workbench task | |
|---|---|---|---|
| Means | Something happened | Someone may need to know | OrviQ is waiting for a person |
| Configurable here | No | Yes, via alert policies | No — created by workflow stages |
Alert policies generate notifications. They do not create Workbench tasks, and no amount of alerting substitutes for a governed workflow stage.
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 bank's alert policy set.
| Policy | Trigger | Recipients | Threshold |
|---|---|---|---|
| Material engagement review due | engagement_review_due | Engagement owner, Head of Third-Party Risk | 30 days |
| Material engagement review overdue | engagement_review_overdue | Engagement owner, Head of Third-Party Risk, CRO | Immediate |
| Material contract expiring | engagement_contract_expiring | Engagement owner, Procurement | 90 days |
What was removed during a review: an "all engagement review due" policy alerting the whole Third-Party Risk team at 60 days across all 94 engagements. It generated a steady background of alerts about low-criticality arrangements and had trained the team to skim.
The replacement policies fire on material engagements only, to named recipients, at thresholds matched to the work involved.
Provider configuration: email delivery configured with a delivery log. When a provider outage occurred for two days, no notifications were delivered — and no obligations were missed, because every one of them was also a Workbench task.
Troubleshooting
"Users are not receiving email notifications." Check provider configuration and the delivery log. In-application notifications and Workbench tasks are unaffected.
"Too many alerts." Review recipients and thresholds. Deduplication prevents repetition of one condition, not breadth of configuration.
"An alert fired repeatedly." Check whether the condition is genuinely resolving and re-triggering, rather than staying true — deduplication covers the latter.
"A user got a notification but no task." It was informational. Not every notification carries an obligation.
"I cannot run the sweep." Requires settings.manage.