Independent IFS Cloud practice · Supply Chain
Clean Core in IFS Cloud: what it really means for Purchasing and Inventory
Key takeaways
- Clean Core IFS Cloud means every change lives inside the Extensibility Framework — not in modified core code — so upgrades stay predictable.
- For SCM, “update-safe” means your Purchasing and Inventory automations survive each R1/R2 release untouched.
- Custom Events, Custom Fields and Workflows are the update-safe building blocks; direct core edits are not.
- Staying inside the core sharply reduces the regression testing you owe every upgrade.
- The SCM Automation Pack is Clean Core by construction — twelve automations built only with standard mechanisms.
Every IFS Cloud upgrade carries a hidden bill. If your Purchasing and Inventory logic was welded into modified core code, someone has to re-test and re-fix it each release — the “upgrade tax” that turns a routine update into a three-month project. Clean Core is how you stop paying it. This piece explains what Clean Core actually means in IFS Cloud, where the line sits between the Extensibility Framework and core modification, and what that changes for a supply-chain team in concrete terms.
1.What does Clean Core mean in IFS Cloud?
Clean Core is a simple rule with large consequences: you never change the standard product; you extend it from the outside. IFS ships the core application — the Purchasing, Inventory, Shop Order and Invoicing logic that every customer receives — and provides a defined layer, the Extensibility Framework, where your own logic is allowed to sit. Keep everything you build inside that layer and the core stays exactly as IFS delivered it. That is a “clean” core.
The reason this matters is upgrades. IFS Cloud is evergreen: new tracks arrive on a regular cadence, and each one may rewrite core packages, views and pages. Anything you left inside the core is overwritten or thrown out of alignment. Anything you built in the extensibility layer is designed to be carried forward. Clean Core is not a style preference — it is the difference between an upgrade you schedule and an upgrade you survive. We unpack that cost in detail in the IFS Cloud upgrade tax.
2.Extensibility Framework vs core modification
The two are not different flavours of the same thing. One is a supported extension point; the other is a liability you carry to every release. Here is the practical split for a supply-chain build:
| Question | Extensibility Framework | Core modification |
|---|---|---|
| Where the logic lives | Custom Events, Custom Fields, Workflows, projections — outside the core | Edited standard PL/SQL, views or client pages inside the core |
| What an upgrade does to it | Carried forward; validated, not rewritten | Overwritten or broken; must be re-applied |
| Who can maintain it | A consultant or a trained key user, in the UI | A developer with core source access |
| Regression test burden | Small and bounded | Large and open-ended |
| Update-safe? | Yes, by design | No |
There is still a place for server-side PL/SQL — but inside an event action, not welded into a standard package. The mechanism, not the language, decides whether a change is Clean Core.
3.What does “update-safe” mean for SCM specifically?
“Update-safe” means a given automation keeps working across an IFS Cloud upgrade without a developer touching it. For supply chain that is a strong promise, because SCM logic tends to be busy: it fires on purchase orders, receipts, stock transactions and supplier records that change thousands of times a day. If that logic sits in the core, every one of those touch-points is a place the next release can break.
Built the Clean Core way, an update-safe SCM automation has three properties:
- It listens to a standard event (a PO line saved, a receipt posted) rather than a modified trigger.
- It reads and writes through standard projections and APIs, so field and table changes are absorbed cleanly.
- It stores its own settings in Custom Fields, never by editing a base table.
4.Concrete Purchasing and Inventory examples
Clean Core is easier to trust when it is specific. Here are automations that solve real supply-chain pain and stay entirely inside the extensibility layer:
- Unconfirmed PO escalation — flag orders the supplier has not acknowledged after your threshold, and chase the right buyer.
- Supplier price-change guard — catch a purchase price that jumps beyond tolerance before the order is released.
- Below-minimum stock alert — notify planning when on-hand crosses the safety point, without a manual report run.
- Invoice-on-hold nudge — surface invoices stuck in hold so they never quietly age past terms.
- Receipt-without-order check — spot inventory movements that do not tie back to an expected receipt.
- Slow-moving stock digest — a weekly view of items aging past their target, straight to the planner.
Each one is a Custom Event with a defined trigger and action — not a change to the Purchasing or Inventory core. If you want the mechanism itself explained, IFS Custom Events explained walks through triggers, actions and PL/SQL, and Quick Reports, Custom Fields and Custom Events shows how the reporting side stays update-safe too.
5.How does staying update-safe cut regression testing?
Regression testing exists to answer one question after an upgrade: did anything we changed stop working? The size of that job is set by how much you changed and where. Core modifications force you to re-test every altered package and every process that touches it — and because a core edit can have side effects far from where it sits, the test surface is hard to bound. That is the open-ended cost that makes upgrades slip.
Clean Core shrinks the surface. Because your logic sits in named, isolated extensions, an upgrade validation is a checklist, not an investigation:
- List your Custom Events, Custom Fields and Workflows — a finite, known set.
- Confirm each still binds to its standard event and projection on the new track.
- Run each automation once in dry-run and compare the result to the last release.
- Sign off. There is no modified core to hunt through, because there is none.
The work goes from “re-test the whole supply chain” to “re-validate a short list.” That is where the upgrade tax disappears.
6.How the SCM Automation Pack embodies Clean Core
The SCM Automation Pack is twelve update-safe automations for Purchasing, Requisitions, Inventory and Invoicing — built from Custom Events, Workflows and, where genuinely needed, PL/SQL running inside an event action. Nothing in it modifies the core. Every scenario ships with a dry-run mode and a frequency cap, and go-live includes a mandatory test week, so you prove behaviour before it touches production. It is Clean Core turned into a product: the events fire, the alerts land, and the next R1/R2 release carries the whole pack forward untouched.
7.Frequently asked questions
Is Clean Core in IFS Cloud the same as having no customisations?
No. Clean Core means customising through the Extensibility Framework instead of modifying the core. You can automate Purchasing and Inventory heavily and still be Clean Core, as long as every change lives in Custom Events, Custom Fields, Workflows and projections rather than in edited standard code.
Can I still use PL/SQL and stay Clean Core?
Yes. PL/SQL is fine when it runs inside a Custom Event action or a supported extension point. What breaks Clean Core is editing standard IFS packages or views directly. The mechanism decides, not the language — the same logic is update-safe in an event action and unsafe welded into core code.
How does Clean Core reduce upgrade cost for a supply-chain team?
It bounds the regression test. Instead of re-testing every modified core package and its side effects, you validate a finite list of extensions against the new track and dry-run each one. Upgrades become a scheduled checklist rather than an open-ended remediation project.
Is the SCM Automation Pack built to Clean Core standards?
Yes. All twelve automations use only standard IFS mechanisms — Custom Events, Workflows and PL/SQL inside event actions — with no core modification. Each ships with a dry-run mode and frequency cap, and go-live includes a mandatory test week, so the pack is carried forward by every future upgrade.
8.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. Based in Kraków, working remotely across Europe and globally in an independent practice built strictly on Update-Safe / Clean Core principles.
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.
Keep your supply chain automations off the core
If your next IFS Cloud upgrade is on the calendar, the safest place for your Purchasing and Inventory logic is the extensibility layer — not the core. On a 30-minute call I’ll show you which automations pay for themselves first, all Clean Core, all dry-run tested before go-live.