Independent IFS Cloud practice · Upgrades & Extensibility
The upgrade that broke your custom check and never told you
Key takeaways
- A custom PL/SQL alert can run successfully through an IFS Cloud upgrade, keep returning results, and still be broken. The failure mode is zero rows, not an error.
- Zero rows is indistinguishable from a quiet month, so the gap goes unnoticed for exactly as long as nobody has a reason to ask why nothing has fired lately.
- The real cost of customisation is rarely the build or the test. It is a silent failure two or three upgrades later, discovered only by the incident it should have prevented.
- A heartbeat check, confirming each rule still returns a plausible baseline rather than just that it runs without error, closes the gap and keeps the rule update-safe.
A custom PL/SQL package built five years ago checks order states every morning and emails purchasing when something needs attention. It survives two IFS Cloud upgrades without a single change. On the third, an upgrade alters a view the package quietly depends on. The package does not throw an error. It runs on schedule, queries successfully, and returns zero rows. For six months, nobody notices, because zero rows looks exactly like a quiet month in purchasing, and a quiet month is not a support ticket. This is the failure mode that testing plans built around “does it still run” miss completely, and it is a more common story on real IFS Cloud estates than most upgrade retrospectives admit.
1.Why does a working check fail silently?
Most regression testing after an upgrade asks one question: does the custom code still execute without throwing an error? That question has an honest, comfortable answer almost every time, because IFS Cloud upgrades are designed to be graceful. A renamed column, a restructured view, or a changed join rarely crashes a package outright. It just changes what the query returns, and a query that used to match forty rows a day can start matching zero without any exception being raised at all.
The people who could catch it are not looking for it, because there is nothing prompting them to look. An upgrade project tracks the things that visibly break: failed jobs, error logs, user complaints. A rule that goes quiet produces none of those. It produces the absence of a thing that was never guaranteed in the first place, and absence is the hardest failure mode to schedule a test for.
2.What does the silent failure actually cost?
The cost is not the broken package. It is everything the package was put there to prevent, arriving unannounced during the exact months it was quietly offline.
- A false sense of coverage. Every day the check runs and reports nothing, the organisation believes a risk is being watched that has, in fact, gone unwatched since the upgrade.
- Discovery by incident. The gap is usually found the way any silent control fails: when the exact problem it existed to catch happens anyway, and someone asks why the alert never fired.
- Compounding exposure. The longer a check has been silently broken, the more upgrades and data changes have piled up underneath it, so restoring it correctly gets harder the later it is found.
- Erosion of trust in automation. Once one silent gap is found, every other custom rule on the estate is reasonably suspected of the same thing, and confidence is expensive to rebuild one manual re-check at a time.
Custom code that fails loudly is a nuisance you fix in an afternoon. Custom code that fails quietly is a risk you carry into every release without knowing it.
3.How do you catch this before the incident does?
The fix is not more error handling inside the check itself. The check was never throwing an error to begin with. The fix is watching the check from the outside: a heartbeat that compares how many rows a rule returned this run against its own recent history, and flags a rule that has gone quiet the same way it would flag one that suddenly went noisy.
A rule that has averaged five to ten hits a week for a year and then returns zero for three consecutive runs is worth a look, regardless of whether “zero is plausible” on its face. This is the same logic used to keep upgrade readiness checks honest: verifying a control still behaves the way it always has, not just that it still exists in the codebase.
4.“Runs without error” versus “verified live”
Both are useful. Only one of them would have caught the six-month gap.
| Runs without error | Verified live (heartbeat) | |
|---|---|---|
| What it confirms | The package executes and completes | The package’s output still matches expected behaviour |
| Catches a broken dependency | Only if it throws an exception | Yes, even if the query still runs cleanly |
| Catches zero-row drift | No | Yes |
| When it is checked | Once, at upgrade testing | Continuously, every run |
| Effort to maintain | None after go-live | Light: one baseline comparison per rule |
Upgrade testing that stops at “it still runs” is necessary and not sufficient. The heartbeat is what turns a one-time test into an ongoing guarantee that survives the upgrade after the one everyone tested for.
5.How do you add a heartbeat without adding noise?
The heartbeat should be quieter than the rule it is watching, not louder.
- Inventory every custom check that fires on a schedule. A silent gap only matters for rules nobody would otherwise notice have stopped.
- Record a rolling baseline per rule. A trailing window of typical hit counts is enough to define what “plausible” looks like for that specific check.
- Run in dry-run for a month. Let the heartbeat log what it would flag before anyone receives an alert about an alert.
- Escalate a heartbeat failure separately from a business alert. “This rule went quiet” is an IT/maintenance signal, not a purchasing one. Keep the two audiences apart.
- Re-baseline after every upgrade. A legitimate change in volume after a release should not be mistaken for a broken dependency, and vice versa.
Built as standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, both the original rule and its heartbeat stay update-safe and avoid the upgrade tax. That is the same discipline that keeps Custom Events maintainable release after release.
6.Frequently asked questions
Doesn’t our upgrade regression testing already cover this?
Most regression testing confirms a package still executes without an error. It rarely confirms the package’s output still matches its historical pattern, which is exactly the gap a zero-row failure exploits.
How would we even know which of our custom rules are at risk?
Any scheduled custom check whose failure mode is silence rather than an error is a candidate: typically anything built as a PL/SQL job or Custom Event that queries and emails without a human reviewing the query result itself.
Won’t a heartbeat just create another alert nobody reads?
Only if it is tuned poorly. Routed to IT rather than to the business audience, and fired only on a genuine deviation from baseline, a heartbeat alert should be rare enough to always be worth opening.
Is this update-safe?
Yes. Both the original rule and the heartbeat that watches it are built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework. There is no core modification, so there is nothing here for the next R1/R2 release to quietly break.
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.
Find out which of your rules already went quiet
A short audit of your scheduled custom checks against their own history will show you, in a day, whether any of them have been silently returning zero since your last upgrade. Fixed price, no changes go live without a review.
