Independent IFS Cloud practice · Supply Chain
When IFS trusts you too much: the hidden cost of overrides without guardrails
Key takeaways
- IFS will let you receive against an unconfirmed PO, ship without checking supplier delivery, or close an order with open lines - that is flexibility, not a defect.
- Each individual override is reasonable in isolation; combined, they can produce a system state that is internally consistent and operationally wrong.
- This is distinct from RBAC and segregation of duties - that governs who can act; this is about the guardrails on the action itself, regardless of who performs it.
- A lightweight validation rule - warn, log or require a reason on the riskiest transactions - keeps the flexibility while removing the silent downstream cost.
IFS will let you receive goods against a purchase order that was never confirmed. It will let you ship to a customer without checking whether the supplier actually delivered. It will let you close an order that still has open lines. None of this is a flaw - it is flexibility, and IFS assumes the user knows what they are doing. Most of the time, they do. The problem is the edge case: a new warehouse operator receives against the wrong order, a buyer closes a PO to tidy up their dashboard, a planner overrides a lead time because the default looked wrong. Each action is reasonable on its own. Together, they create a system state that is internally consistent and operationally wrong, and it surfaces weeks later, in a different department, as someone else’s problem. Flexibility without guardrails is not freedom. It is deferred cost.
1.Why does IFS allow this in the first place?
IFS is built for organisations where the standard path is followed most of the time and the exception path is needed occasionally - a receipt has to be corrected, a stuck order has to be closed to keep reporting clean, a lead time genuinely needs overriding because the master data is wrong. Blocking every one of those actions outright would make the system unusable on the day it is actually needed most, so the platform leaves the door open and trusts the user standing in front of it.
The risk is not the door being open. It is that nothing records why it was opened, or checks whether the same door has been opened an unusual number of times this month, by the same person, on the same supplier. A single override is a judgement call. A pattern of overrides is a signal that something upstream is broken - and without a guardrail, nothing is watching for the pattern.
2.What does an unguarded override actually cost?
The cost rarely lands where the override happened. It travels downstream, then surfaces as someone else’s exception:
- Silent state drift. A closed order with open lines looks finished to reporting while goods are still owed - nobody chases them because nothing says they are outstanding.
- Delayed discovery. The gap surfaces weeks later, when the missing goods are needed, by which point the original context and the person who made the override are both gone.
- Cross-department blame. The team that inherits the exception was not the team that created it, so the investigation starts from zero instead of from the cause.
- Repeat exposure. Without visibility into how often an override is used, the same edge case keeps recurring, quietly, indefinitely.
Flexibility without guardrails is not freedom. It is deferred cost, and someone else always ends up paying it.
3.How do you see it happening in IFS Cloud?
Every override leaves a trace in IFS whether anyone looks at it or not: a receipt posted against an order with no confirmation, an order closed while lines remain open, a lead time changed from its default value. The data to spot the pattern is already there; it simply is not aggregated anywhere a person would think to look.
Surfacing it is a matter of counting, not inventing: how many receipts this month landed against unconfirmed orders, how many orders were closed with open lines, by whom, and how that compares to the same period last quarter. A rising count on any one of those is a far better early warning than waiting for the downstream department to notice goods that never showed up.
4.No guardrail versus a systematic one
The choice is not between flexibility and control - it is between an override that leaves no trace and one that is allowed, but seen.
| No guardrail | Systematic | |
|---|---|---|
| Prevention | None - the action always succeeds silently | Warn, log, or require a reason on the riskiest cases |
| Visibility | None until the exception surfaces elsewhere | Logged at the moment it happens |
| Pattern detection | Nobody is counting | Volume and repeat-offender trends visible |
| Owner | Whoever inherits the downstream mess | The team closest to the override, by rule |
| Fails when | Always, quietly | Never sleeps |
Nothing here blocks the legitimate override - the operator can still receive against the unconfirmed PO, the buyer can still close the order. The guardrail adds a reason field, a log entry, or a warning that makes the action visible instead of invisible, so the person doing it thinks for one extra second, and everyone downstream can see it happened.
5.How do you roll it out safely?
Guardrails are only useful if they inform rather than obstruct, so start light and add friction only where the data justifies it.
- Rank the risky actions. List the overrides most likely to create downstream cost - receiving unconfirmed, closing with open lines, overriding lead times - and pick the top one or two.
- Run in observe-only. Log every occurrence for a few weeks without changing the user experience at all, to see the real volume.
- Add a soft check. Introduce a warning or a required reason, not a hard block, and watch whether it changes behaviour.
- Pilot on one team. Confirm the guardrail catches genuine risk without slowing down legitimate work before widening it.
- Review after a month. Check what was caught, what was ignored, and whether the threshold needs tuning.
Because the whole thing is built inside the IFS Extensibility Framework - standard Custom Events, Workflows and PL/SQL - it is update-safe. There is no core modification for the next release to break, so you avoid the upgrade tax entirely.
6.Frequently asked questions
Does adding a guardrail block users from doing their job?
Not if it is designed as a warning or a logged reason rather than a hard block. The goal is visibility on the riskiest overrides, not preventing legitimate exceptions from being handled the same way they always have been.
Isn’t this the same as RBAC or segregation of duties?
No. RBAC controls who is permitted to perform an action. This is about the action itself - making a risky transaction visible and traceable regardless of which authorised user performs it. The two controls are complementary, not overlapping.
Which transactions are worth guarding first?
Start with overrides that combine high frequency with high downstream cost - receiving against unconfirmed orders and closing orders with open lines are common starting points, but the right list depends on where your own exceptions actually originate.
Is this update-safe?
Yes. The guardrail is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework - no core modification. Nothing here is the kind of customisation that the next R1/R2 release quietly breaks.
7.About the author
Dariusz Myśliwiec - 25+ years in ERP and supply chain, 17+ on 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 - 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 the risky overrides visible
If you suspect a handful of reasonable-looking overrides are quietly creating exceptions somewhere downstream, an observe-only week will show you the real volume. On a 30-minute call I’ll map the highest-risk transactions to a lightweight guardrail - fixed price, dry-run before anything changes.
