Deutsch (Deutschland) 
Polski (PL) 
Independent IFS Cloud practice · Supply Chain
The fastest way to get an alert ignored - and the restraint that fixes it
Key takeaways
- Exception reporting fails for a reason that has nothing to do with the data. It fails because it treats a person like a queue: send every line every day and within a week the report has its own folder nobody opens.
- Good exception handling is an exercise in restraint: one message per person per day, only what changed since yesterday, only what actually needs a decision.
- Volume feels like diligence. It is the opposite, because every alert that did not need sending makes the next one easier to ignore.
- An alert nobody reads is worse than no alert at all. It quietly trains the room to look away, and it takes the important one down with it.
Somewhere in most planning teams there is a rule that fires on every line, every day, whether anything changed or not. It started as a good idea: nobody wanted to miss an exception, so the system was set to flag everything that might matter. Six months later that report has its own folder, and the folder has an unread count in the thousands. The one email in there that actually needed a same-day decision looked exactly like the two hundred that did not, so it waited with them, and by the time anyone opened it the delivery date had already passed. The team is not careless. The alert simply stopped reading as information the day it started arriving whether or not anything had happened. This article covers why exception volume spirals in the first place, what the fatigue actually costs, how to see it happening in IFS Cloud, and how to redesign the alert so the one message that matters is the only one that arrives.
1.Why does exception volume spiral in the first place?
Nobody sets out to build a report nobody reads. It starts from a defensible instinct: better to over-notify than to miss something. So the first version of the rule casts a wide net (every open order, every line below target, every supplier with a date in the past), and it ships because wide coverage looks like thoroughness on a demo. What it actually does is hand the recipient a sorting job disguised as an alert. Every line demands the same five seconds of attention to work out whether it is the one that matters, and most of them are not.
The volume rarely gets revisited once it is live, because turning an alert down looks like reducing visibility, and nobody wants to be the person who quietly removed a safety net. So the report keeps firing at full volume long after everyone has learned to skim past it, and the one rule meant to catch the important exception is buried inside the noise it created for itself.
2.What does alert fatigue actually cost?
The cost is not the noise itself. It is what the noise trains people to do to every message that arrives after it, including the ones that matter:
- Trained blindness. After enough irrelevant alerts, the brain stops distinguishing them from the important ones, so every message gets the same half-second glance.
- Delayed decisions. The one line that needed action today sits unread in a folder built for lines that needed nothing, and it surfaces only once the deadline has already passed.
- Wasted triage time. Someone still has to open the report occasionally and manually work out which of two hundred lines is real, which is the exact job automation was supposed to remove.
- Eroded trust in every future alert. Once a report earns a reputation for noise, people stop trusting the next system that tries to notify them of anything.
An alert nobody reads is not neutral. It is worse than no alert, because it trains the room to look away and it takes the important one down with it.
3.How do you see this happening in IFS Cloud?
Fatigue rarely announces itself with a complaint. It shows up as a folder rule quietly created to route the alert straight past the inbox, as a recipient who stopped replying to the distribution list months ago, or as a Custom Event log showing the same message firing daily against the same handful of orders with no change in outcome. Any of those is a working definition of an alert that has stopped functioning as an alert.
The fix starts with counting, not redesigning. For each recurring notification, ask how many messages it sent last month, how many of those represented a genuine change since the prior message, and how many required a decision from the recipient. If the second and third numbers are far below the first, the rule is firing on presence rather than change, and that gap is exactly what a Custom Event condition should be checking for instead.
4.Send-everything alerting versus disciplined exception design
The difference is not sophistication. It is discipline applied to a small set of rules: fire on change, not on presence; cap it at one message per person per day; and route only the lines that need a human decision. The same Custom Event mechanics that power every rule in the SCM automation catalogue support both patterns, and the difference is entirely in how the condition and the frequency cap are written.
| Send everything | Disciplined design | |
|---|---|---|
| Trigger | Presence of a condition | Change in a condition |
| Frequency | Every run, regardless of prior sends | Capped: once per person per day |
| Content | Every line that matches | Only lines needing a decision |
| Recipient reaction | Skim, ignore, folder rule | Read, act |
| Trust over time | Declines | Holds |
A rule that fires less often is not a weaker rule. It is the same detection logic with an extra condition (has this changed since I last told you) that turns a queue of lines into a short, trustworthy list.
5.How do you roll out disciplined alerting safely?
Redesigning a live alert without a plan just creates a different kind of chaos. Tighten it in stages, and let the recipients confirm each step before the next.
- Audit the current volume. Pull a month of send history and count how many messages represented a real change versus a repeat of yesterday’s state.
- Define “change” explicitly. Agree the condition that separates a genuine exception from a line that simply still exists: a status flip, a date slip, a threshold crossed.
- Run the new condition in dry-run. Log what the tightened rule would have sent last month and compare it against what actually needed action.
- Cap the frequency. One message per person per day, consolidating multiple exceptions into a single digest rather than separate emails.
- Pilot with one team, then review. Ask directly whether they are reading it now, and adjust the threshold before rolling it out further.
Because the redesigned rule is still built inside the IFS Extensibility Framework (standard Custom Events, Workflows and PL/SQL), it is update-safe. Tightening the condition changes what fires, not the core, so the next release does not undo the work.
6.Frequently asked questions
What is alert fatigue in a supply chain context?
It is the state where a recipient has received so many low-value notifications that they stop reading all of them carefully, including the rare one that actually needs same-day action. The exception itself may still be correctly detected, but the failure is entirely in whether anyone notices.
Isn’t it safer to over-notify than to miss something?
It feels safer, but it produces the opposite outcome. Once a report earns a reputation for noise, people stop trusting it entirely, which means the genuinely important exception is now less likely to get read than it would be inside a shorter, trusted list.
How many alerts per day is too many?
There is no universal number, but one consolidated message per person per day is a reliable working target. If a rule needs to send more than that to cover genuine changes, the underlying condition is usually too broad and worth tightening first.
Will tightening an existing alert risk missing something important?
Not if you run the tightened condition in dry-run first and compare it against a month of history before switching it on. That comparison is exactly what confirms the new rule still catches everything that mattered, just without the lines that did not.
7.About the author
Dariusz Myśliwiec: 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally, so you talk to the consultant who builds it, not a sales layer.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Make your alerts worth opening again
If your team has a report with its own unread folder, the fix is rarely more alerting but rather less, aimed better. A 30-minute call is enough to look at one live rule and sketch what a disciplined version would send instead (fixed price, dry-run before anything changes).
