Exceptions are being rebuilt. We’re actively reworking how exceptions are detected, grouped, and surfaced, and stronger controls are coming soon. This page describes how it works today — parts of it may be out of date or change as the new version rolls out. If what you see doesn’t match what’s here, email support@owlery.ai and we’ll tell you where it stands. If you are an Enterprise customer with individual subsidiary organizations, remember that shipper settings are organization specific. Settings must be configured at the individual subsidiary organization level to ensure each subsidiary’s operations work as expected.
Dashboard → Shipper Settings → Exceptions
An exception is Owlery flagging that a shipment needs someone to look at it — a missing document, a tracking update that never arrived, or a date that has slipped. Exceptions collect in your Needs Attention queue, which is the list your team works through.
The queue is only useful if everything in it is worth acting on. These settings are how you keep it that way.
Excluded Carriers from Exceptions
What it does: Loads assigned to the carriers you list here stay out of the Needs Attention queue. Carriers are listed by their integration name, so you’re picking recognizable names rather than codes.
When you’d use it: When an integrated carrier reliably raises exceptions that aren’t real problems. A common case is a carrier whose system doesn’t send the tracking updates Owlery expects, so every load with them looks like it’s missing information. Excluding them stops that noise burying the exceptions your team actually needs to act on.
When you wouldn’t: Don’t use it to quiet a carrier with genuine service problems. Those exceptions are exactly the ones you want in front of your team.
This hides, it doesn’t disable. Exceptions are still raised, stay open, and remain visible on the load itself — they’re just not queued for action.
