Independent IFS Cloud practice · Clean Core & Integration
Reading without writing: the safest way to monitor IFS Cloud
Key takeaways
- A read-only OData integration watches order states, delivery dates and stock levels through IFS Cloud’s own projections — no custom objects planted in the core.
- Every write path you add to a monitoring tool is something you must test, patch and defend at the next R1 or R2 upgrade; a read-only account never asks that of you.
- A read-only integration cannot corrupt data and cannot violate a business rule, because it never touches the write side of IFS Cloud.
- Nothing installed, nothing to uninstall, nothing that breaks quietly on the next release - the monitoring layer stays entirely inside Clean Core.
You can learn a great deal about a supply chain by reading IFS Cloud and never writing a single row back to it. That is the whole idea behind a read-only OData integration: a dedicated account, a handful of standard projections, and a monitoring layer that watches order states, delivery dates and stock levels the same way any IFS Cloud client already does. Nothing installed in the database. No custom objects planted in the core. Nothing to uninstall if the project ends. Most teams do not reach for read-only by design, though — they reach for it after a writeback integration has already cost them a weekend during an upgrade. The moment a monitoring tool starts changing data, even in small, well-intentioned ways, it stops being something you watch and becomes something you have to test, patch and defend at every release. This article covers why that write path creeps in, what it actually costs, and how to build the alternative properly.
1.Why do monitoring tools end up writing to IFS Cloud?
Nobody sets out to build a fragile integration. It starts small: a monitoring tool flags a stale purchase order, and someone asks whether it can also mark the alert as acknowledged so the list does not fill up with noise. That single write field feels harmless. It is one column, one status flag, one small mercy for whoever reviews the output.
The trouble is that IFS Cloud does not have a concept of a harmless write. Every write path touches a business object with its own validation, its own state machine and its own rules that change release over release. A field that accepted any value in one version can carry a new mandatory dependency in the next. What began as a convenience for the monitoring tool becomes a customisation the upgrade team has to find, understand and requalify — usually without knowing it exists, because nobody wrote it down as an integration.
2.What does a write path actually cost you?
The cost is not visible on the day you add the write. It shows up two or three upgrades later, spread across four places:
- Regression testing. Every write path is a customisation surface QA has to rediscover and reverify at every R1 and R2, whether anyone remembers building it or not.
- Upgrade fragility. A write that worked cleanly against last year’s business logic can violate a rule the next release tightens, and it usually fails at the worst possible moment — mid-upgrade, in production.
- Elevated permissions. A monitoring account with write access is a bigger target and a bigger blast radius if the credentials leak or the tool misbehaves.
- Ongoing maintenance. Every writeback needs its own error handling, its own retries, and someone who owns what happens when it fails silently at three in the morning.
The cheapest integration to maintain is the one that never asked IFS Cloud to trust it with a write.
3.How do you build it read-only in IFS Cloud?
The mechanics are standard, not exotic. IFS Cloud already exposes the data a monitoring layer needs through its own OData projections — order state, confirmation status, delivery date, stock quantity — the same projections the standard client uses. You create a dedicated integration account, attach a permission set that grants read access to exactly the projections in scope, and nothing else. No custom entity. No new table. No PL/SQL package sitting in the database waiting to be discovered by the next upgrade.
From there the monitoring tool polls on a schedule, filters for the states that matter, and raises whatever alert or dashboard update the business actually needs — entirely outside IFS Cloud. The writing, if there is any, happens in an email system, a Teams channel or a ticketing tool, never back into the ERP. IFS Cloud stays exactly as clean as it was before you started watching it.
4.Writeback integration versus read-only monitoring
Put side by side, the two approaches do not just differ in risk profile. They differ in how much of your time they quietly consume, upgrade after upgrade.
| Writeback integration | Read-only monitoring | |
|---|---|---|
| Upgrade exposure | Every write path retested each release | Nothing to retest — the projection is standard |
| Permissions needed | Write access to core business objects | Read-only, scoped to a handful of projections |
| What breaks on R1/R2 | Custom write logic against changed rules | Nothing — you consume the same data IFS ships |
| Audit surface | Every write is a change someone must trace | None — the tool leaves no trace in the system |
| Worst-case failure | Silent data corruption or a blocked release | A stale read, never a broken transaction |
None of this means writeback integrations are always wrong. Some processes genuinely need to change a state in IFS Cloud. But a monitoring and alerting layer is not one of them, and treating it as read-only from day one removes an entire category of upgrade risk before it can accumulate.
5.How do you roll it out safely?
Building it read-only from the start is the easy part. Rolling it out without creating a second problem — an integration account with more access than it needs — takes a little more discipline.
- Scope the projections. List exactly which entities — order state, confirmation, delivery date, stock level — the monitoring layer needs, and nothing more.
- Create a dedicated read-only account. A named integration user with a permission set that grants read access only, never write privileges, even where write access looks convenient.
- Test against a non-production environment first. Point the read-only layer at a test or UAT tenant before it ever touches live data.
- Cap the polling frequency. Poll on a schedule that respects IFS Cloud’s own performance envelope, not on every possible trigger.
- Review the account after every upgrade. A five-minute permission check per R1 or R2 cycle is the entire ongoing maintenance cost.
Because the account only ever reads, there is nothing here for the IFS Extensibility Framework to protect you from — no core modification, no custom object, no write path for the next release to break. It stays update-safe by construction, not by discipline you have to remember to apply.
6.Frequently asked questions
Does a read-only OData integration need any custom development in IFS Cloud?
No. It uses the standard OData projections IFS Cloud already exposes, accessed through a dedicated integration account with a read-only permission set. There is nothing to build inside IFS Cloud itself.
What can a read-only integration actually see?
Whatever the permission set grants and nothing more. Most monitoring layers only need order state, confirmation status, delivery dates and stock levels — a small, well-defined slice of the data IFS Cloud already holds.
Can a read-only integration still send alerts and take action?
Yes. The read triggers the alert; the action — an email, a Teams message, a ticket — happens outside IFS Cloud. Nothing is written back into the ERP, so the action never becomes a customisation to maintain.
Is this approach compatible with Clean Core?
Yes, directly. A read-only integration installs nothing in the database, modifies no core object and leaves no trace for an upgrade to break. It is one of the simplest ways to add monitoring without touching your Clean Core position.
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.
Monitor without the upgrade tax
If your monitoring layer already writes back into IFS Cloud, a read-only rebuild is usually smaller than it sounds. On a 30-minute call I’ll map what your alerts actually need to read, and what can come out of the write path entirely — fixed price, dry-run before anything changes.
