Set Up Notifications
You shouldn't have to go looking for problems. Notifications tell you the moment a credential is expiring, a status changes, or a worker turns up on a ban register — so the right people can act without checking the Compliance Overview manually.
Alerts reaching the right people through the right channels — your own inbox, your team's Microsoft Teams or Slack channel, and optionally the workers themselves.
Step 1: Open Notifications
In the left menu, click Settings, then under Manage click Notifications.
Step 2: Set your personal alert level
At the top, Your alerts — tagged Only you — controls which alerts you personally receive. It applies to your account and nobody else's. Choose an Alert level:
- All alerts — Expiring Soon, Expired, Revoked, Suspended, and Not the holder's — see the five subject lines
- Critical only — Expired, Revoked, Suspended, and Not the holder's: everything except the advance warning
- Custom — tick exactly which alert types you want
A person who has never saved a preference receives all credential alerts. That's the point — somebody who hasn't chosen shouldn't be the person who misses an expiry — but it does mean alerts start arriving without anyone switching them on. See Stop receiving alerts if that's you.
Everyone can set their own preferences here. The remaining sections are admin-only and set the behaviour for the whole organisation.
Step 3: Choose who in the workforce gets notified
Under Workforce notifications, decide whether Oho emails your people directly:
- Notify workers about their expiring credentials — emails each worker at the address on their profile as their credentials approach expiry.
- Also notify the worker's manager — copies the manager, with a From: choice of how early to start.
Turning on worker emails contacts your workers directly — they don't need an Oho login and can't opt out individually, so make sure your organisation has told them to expect these. Oho gives you a grace window: emails begin one hour after you save, so you can turn it back off before then to cancel.
Step 4: Set the expiry timing
Under Expiry timing, set how far in advance a credential is flagged — Expiring (default 30 days) and Expiring Soon (default 7 days). You can add per-credential-type overrides so, say, a First Aid certificate warns earlier than a card that renews quickly.
The warning alert fires once, at your Expiring lead time — raise that value if you want more notice. See how expiry is watched for how this differs from the amber badge on the credential itself.
Step 5: Add a delivery channel
Under Notification channels, choose where org-wide alerts are delivered — any combination of:
- Email — one or more shared inboxes (e.g.
[email protected]), each optionally scoped to the organisations it covers. You can also choose which alert types reach them. - Microsoft Teams — paste the channel's Incoming Webhook URL; the page includes step-by-step instructions for getting one.
- Slack — paste the channel's Incoming Webhook URL, again with instructions on the page.
For Teams and Slack you can also choose which alert types post to that channel.
A shared inbox receives an alert as well as every individual who's subscribed to it, not only when nobody else matched. So one credential expiring can be several emails: one per matching shared inbox, plus one per subscribed person. Worth knowing before you add the third inbox.
Step 6: Save
Click Save to apply your changes.
The Delivery log tab on the same page shows recent notifications and where they went — useful when someone says they didn't get an alert. It holds the most recent 100 deliveries and no more: it's recent evidence, not an archive. After a large burst those 100 can cover less than an hour, so check it promptly or you'll be looking at the tail of the story.
This page controls when alerts send and to whom. To change how the emails themselves look and read — wording, branding, and dynamic details — an Admin can customise the email templates.
Alert emails you'll receive
Every credential alert Oho sends has a fixed subject line, built from the alert type and the credential's name. There are five:
| Subject line | When Oho sends it | What to do |
|---|---|---|
| Credential Expiring Soon — credential | The credential first comes inside your expiry lead time (see Step 4) | Chase the renewal while there's still time |
| Credential Expired — credential | Its expiry date has passed | The worker is non-compliant for this credential now |
| URGENT: Credential Suspended — credential | A register reported the credential suspended | Act on it — check where the worker is rostered |
| URGENT: Credential Revoked — credential | A register reported the credential revoked, cancelled or withdrawn | Act on it. A withdrawal is the issuer's decision about the person |
| URGENT: Credential may not belong to this worker — credential | The name the register holds doesn't match the worker the credential sits on | Open the credential and compare the names — usually a mistyped number pointing at somebody else's card |
The same subject goes to everyone owed a copy of that alert: admins, the worker's manager, and the worker themselves where you've turned those on.
The URGENT: prefix is part of the subject for suspensions, revocations and holder mismatches, and absent from the two expiry subjects. It isn't a priority Oho works out per credential, and it isn't related to the Urgent / High / Medium / Low priorities on the Review & Decide queue — those are a different thing entirely and never reach an email subject.
If your organisation has saved its own email template for an alert type, that template's subject replaces the one above. The template editor starts a suspension template off at Credential Suspended — {{credentialName}}, without the prefix — so a tenant that saved a template for suspensions, then had it stop applying to some sends, is the usual reason both URGENT: Credential Suspended and Credential Suspended turn up in the same inbox. Check Settings → Customize → Email Templates to see which alert types you have a template for, and customise the email templates to change a subject.
Before a large import or migration
Alerts are driven by credential status, not by how a credential arrived. Loading several hundred credentials at once — a migration, a first spreadsheet import, a new HR connection — means Oho works out each one's status as it lands, and every one that's already expired, suspended or inside your expiring window is a real alert with real recipients.
The arithmetic is what catches people out, because each alert goes to every matching shared inbox and every subscribed person. A few hundred credentials against a handful of recipients is comfortably four figures of email, overnight, to an audience who weren't expecting it.
Before a big load, pick whichever of these fits:
- Load first, subscribe after. The least disruptive order. Bring the data in, let the statuses settle, then turn alerts on.
- Narrow who's subscribed while it runs. Shared inboxes only, or a short list, rather than everyone's personal preferences.
- Mute the alert types you expect a wave of. Under Notification channels, choose which alert types reach the shared inboxes — Expired is usually the one.
- Silence automated alerts for the window. Settings → Developer → Developer Settings can silence background alerts for 1, 4 or 24 hours. Alerts suppressed during that window are not re-sent afterwards, which is the point, and also the risk.
- Watch the first run, not the whole thing. Import a small slice, read what arrives, then do the rest.
Related: Developer settings for the testing toggles, and Import from a spreadsheet for the load itself.
Stop receiving alerts
To stop your own alerts without giving up anything else, turn off the switch beside Your alerts at the top of the page and save. That's the whole answer — you don't have to untick the alert types one at a time, and there's no None level to choose.
It costs you nothing but the emails. Your alert preferences aren't tied to your role. A Super Admin who switches their alerts off keeps every permission they had — the two settings don't know about each other. Customers moving from the old Oho often expect this to be a trade-off; it isn't.
Your personal switch governs the alerts addressed to you as a subscriber. It doesn't cover:
- Org-wide channels. Shared inboxes, Microsoft Teams and Slack under Notification channels send regardless of anybody's personal preferences. If your own address is one of the shared inboxes, you'll keep receiving everything until an admin removes it there.
- Workforce notifications. Emails to workers and their managers are a separate switch, under Step 3.
- Requests you send. Fetch and recruitment check emails are replies to something a person asked for, so they aren't governed by alert preferences.
Only you can change your own preferences
There is no way for an admin or for Oho support to set another person's alert level. The setting belongs to the signed-in account, and the operation that saves it takes no user — so "can you turn these off for me?" has to come back as "open Settings → Manage → Notifications and turn off Your alerts".
This is a real change from the old Oho, where support could do it on someone's behalf. Nothing support configured there carried across: preferences weren't part of the move, so every account started with no saved preference, which means all alerts.
What an admin can do on someone's behalf is remove their address from a shared inbox under Notification channels, which is often the part people are actually receiving.
When the alerts don't arrive
Work down this list before assuming nothing was sent.
Alerts are per person, not per role. Being an admin subscribes you to nothing in particular, and it doesn't opt you out of anything either. Each person's alert level is their own setting on this page. Someone who has never opened it receives all credential alerts; someone on Critical only gets no advance warning at all, only the post-mortem. If a particular person isn't getting something, check their own level rather than their role.
A new subscription doesn't backfill. Oho raises the expiring warning once, as a credential crosses your Expiring lead time. A credential already inside that window has spent its warning — subscribing today covers what crosses the line tomorrow, and everything already in-window stays quiet until it expires.
Don't rely on one recipient. Alerts stop silently when the only person subscribed to them is removed. Nothing warns you and nothing re-routes. Have at least two people subscribed, or set the org-wide catch-all address under Notification channels so there is always somewhere for an alert to land.
Check the Delivery log on this page before going further. It shows what was sent and to whom, which separates "Oho didn't send it" from "it was sent and didn't arrive" — and those have completely different fixes.
Alerts about someone who left? Deleting a worker now also stops their credentials being scanned and alerted on. A worker deleted before that behaviour shipped may still be marked active, so if you're getting alerts about someone long gone, restore them, set them inactive, and delete again — or just set them inactive. See Offboard a worker.
What's next
- Developer settings — test notifications against your own address before turning them on for everyone
- Customise email templates — shape the wording and branding of the emails these alerts send
- Understand your Compliance Overview — the dashboard your notifications point back to
- Send a fetch request when an alert means you need details only the worker has