Notifications and email

Only active rules are loaded, and they are looked up by exact event type. A rule listening for the wrong event is indistinguishable from no rule at all — it never appears in any log because it was never considered.

Open the rule at Customization → Notification Rules, confirm it is active, and check the event it is bound to. If you are not sure which event your workflow raises, start from a rule you know works and compare.

Filter conditions match a field on the event against a list of accepted values. A field that is missing from the event fails the condition just as surely as a wrong value does, so a condition on a field that only some events carry will filter out the rest.

Remove the condition to confirm that is the cause, then add it back more narrowly. Conditions are combined with AND: every one of them has to match.

Cooldown is per rule and per entity, not per rule overall. A second trip raising the same event still notifies immediately; the same trip raising it again inside the cooldown does not.

The field is Cooldown Period (minutes) on the rule. Set it to 0 for no cooldown. Critical events ignore it entirely.

A rule with active hours or active days set does not discard out-of-window events — it holds them until the window next opens, then releases them together. A morning flood of overnight alerts is this working as intended.

If a rule seems to queue everything, including events well inside the window, clear Active Days and rely on Active Hours alone, then test again. If that changes the behaviour, report it to support with the rule name — a rule with no hours and no days set is always in window.

Recipients come from three sources, and all three can quietly yield nothing:

• A role with no members. The role is resolved, the member list comes back empty, and the rule moves on.
• A dynamic reference that does not apply. The trip-driver reference only resolves when the event is about a trip and that trip has a driver — an unassigned trip yields nobody.
• A directly named user who has since been removed.

Add a named fallback recipient to any rule that matters. A rule with a single role-based recipient is one staff change away from being silent.

Each recipient has a rolling cap of 50 notifications per hour across all rules. Beyond it, that person is dropped from the send while everyone else still receives it. The cap resets on its own.

If a person is routinely hitting it, the fix is upstream: raise the cooldown on the noisy rule, or narrow it with filter conditions. Critical events are exempt from the cap, so genuinely urgent alerts still get through.

Push is filtered by each person’s own notification preferences before any device is looked up, and the types are separate — trip updates, fleet alerts, inspection failures, driver updates, system and general. They manage these themselves at Settings → My Notifications.

If preferences are fine, they may simply have no registered device: a send with no eligible devices is recorded as sent with zero successes rather than as a failure, which is why the log can look healthy. See the driver app troubleshooting page for how to get a device registered again.

Recipient IDs are resolved to addresses at send time. A user who cannot be resolved, or who has no address, is skipped and logged — never allowed to fail the whole send. Check the user record first.

If the address is present and correct, the next suspects are the recipient’s spam folder and their organisation’s mail filtering. Notification email comes from one sending address for the whole environment, so a filter that catches one message tends to catch all of them.

This is intended: one message with the recipients on BCC, rather than one message per person. It keeps addresses private and avoids a burst of near-identical sends. It also means replying to all is not possible, so do not use a notification rule where a conversation is expected.

Trip failures, vehicle breakdowns, SOS alerts and geofence violations always go out immediately. Trip exceptions are treated case by case: only ones carrying critical severity bypass, while minor and major exceptions obey quiet hours like anything else.

You cannot turn that off per rule. If a critical alert is going to the wrong people, change the rule’s recipients rather than trying to throttle it.

A webhook channel needs a URL, and the URL is checked when you save rather than on every delivery, so a bad target fails once with a clear message instead of silently on every event.

Addresses on internal or private networks are refused. Use a publicly reachable HTTPS endpoint. A host that only resolves to a private address at call time is refused at that point instead, so a webhook that saved fine can still fail to deliver.

Testing sends to one named person and tells you the channel works and the credentials are right. It does not prove the rule matches your events, that its recipients resolve, or that it is inside its active window.

So a successful test narrows the problem rather than clearing it. Go back to the first section of this page and work through the checks in order.

Four conditions all have to hold, and any one of them stops it silently:

• Escalation is enabled on the rule. It is a separate section of the rule form, with its own recipients and channels.
• The notification has not been acknowledged.
• The rule’s escalation timeout has actually elapsed since it was sent.
• The escalation recipients resolve to at least one person.

A notification also escalates only once. After the first escalation is recorded it is marked as escalated and will not repeat, so an unacknowledged alert does not turn into a storm.

They do not pass through notification rules at all, so quiet hours, cooldowns and preferences are irrelevant. If one has not arrived, check the address on the user record and the recipient’s spam folder, then re-send from the user.

The three refusals a link can give are distinct and worth reading carefully: invalid, already used, and expired. Already used means the account is set up and the person should sign in normally. Expired means you re-send. Invalid usually means the link was truncated by a mail client — ask them to copy the whole URL.