Independent IFS Cloud practice · Automation & Governance
The thing AI did not make cheaper in your ERP
Key takeaways
- A model can draft an OData query against your IFS Cloud projections in minutes — writing automation code has gotten close to free.
- Being accountable for what that code does to a live ERP at six in the morning, unattended, did not get cheaper at all — the model has no name to put under the output.
- A working script and an owned, reviewed, safely-scoped automation are not the same deliverable, even when the code is identical.
- Before connecting anything AI-assisted to IFS Cloud, ask one question: when this goes wrong at 6am, whose name is on it?
Writing the query got nearly free this year. Point a model at your IFS Cloud projections and it drafts a working OData call in minutes — work that used to take a developer half a day. That shift is real and it is useful. But it quietly moves the hard part of ERP automation somewhere else, and a lot of teams have not noticed the move yet. The code stopped being the scarce, valuable thing. What did not get any cheaper is standing behind what that code does once it runs unattended against live purchase orders, live suppliers and live customers, at an hour nobody is watching. This article is about that gap — between generating automation and being accountable for it — and why it matters more, not less, the easier automation gets to produce.
1.Why did this gap open now?
For most of the history of ERP customisation, the scarcity was technical: someone had to know the schema, know PL/SQL, know how IFS Cloud projections and Custom Events actually fit together. That scarcity acted as an accidental filter. If you could write the automation, you had usually also spent enough time in the system to have a feel for what could go wrong when it ran against real data.
A model removes the technical filter without adding the judgment that used to come bundled with it. Someone who has never opened IFS Cloud can now get a plausible-looking PL/SQL block or OData call in minutes. The code may well be correct. What is missing is the part that was never really about writing code: knowing what this specific query will do the first time it runs over five years of history, on a Monday morning, against suppliers who will actually receive the emails it sends.
2.What does the missing accountability actually cost?
Nothing, right up until the automation does something it should not have — and then the bill arrives all at once.
- An external mistake. A first run that was never scoped or rate-limited can email hundreds of suppliers or customers a message they should never have received, with your company's name on it.
- Unbounded blast radius. Code that looks correct against a test case can behave very differently the first time it runs against the full history of a live table — and nobody scoped what the full run would actually do.
- Nobody to call at 6am. When a generated script fires unexpectedly overnight, the org needs a name that can explain it, stop it and fix it — not a chat transcript.
- Confidence outpacing scrutiny. Code that arrives instantly and looks polished gets less scepticism than code that took a developer a day to write, precisely when it deserves more.
A model does not take the blame. It has no name to put under the output.
3.Where does this show up in an IFS Cloud estate?
It rarely shows up as a dramatic outage. It shows up as a Custom Event or a scheduled task nobody can quite explain in a change review — one whose logic is sound but whose author cannot say, from memory, what happens on its first production run against five years of order history, or who reviewed the recipient list before it went live.
The tell is usually a one-line answer to a two-part question. Anyone can usually explain what a piece of generated automation is supposed to do. Far fewer can explain, without checking, who approved it running against production, what its blast radius is if the assumption behind it turns out to be wrong, and who gets paged if it misfires.
4.AI-drafted code versus accountable automation
The code itself can be identical. What separates the two columns is everything wrapped around it.
| AI-drafted script | Accountable automation | |
|---|---|---|
| Author on record | Whoever prompted it, informally | A named owner, documented |
| First-run behaviour | Untested against full history | Dry-run against real data before go-live |
| Blast radius | Unknown until it runs | Scoped and rate-limited in advance |
| Who gets paged | Whoever notices first | A defined owner with context |
| Update-safety | Not considered | Built inside the Extensibility Framework |
None of this argues against using AI to draft the query — it is a legitimate accelerant for the part of the work that was never the risky part. It argues for treating the draft as a starting point that still needs an owner, not a finished deliverable because it ran without an error.
5.How do you use AI-assisted drafting without losing accountability?
The goal is not to slow down the drafting. It is to make sure ownership catches up to it before anything touches production.
- Name an owner before the first run. Whoever prompts or accepts a generated script signs their name to it — not the tool that helped write it.
- Dry-run against real history first. The first execution against five years of orders happens in a mode that logs what it would have done, not one that actually sends anything.
- Scope the blast radius explicitly. Cap volume, restrict recipients, and rate-limit anything that emails or writes externally until the behaviour is proven.
- Review before go-live, every time. A second person checks the logic and the dry-run output — AI-assisted origin does not earn a shortcut, it earns the same review any custom code gets.
- Keep it inside the Extensibility Framework. Whatever generated the first draft, the delivered rule is standard Custom Events, Workflows and PL/SQL — update-safe, no core modification, reviewable by a human who can be paged.
The same discipline that keeps Custom Events and a Clean Core maintainable applies whether a person or a model drafted the first version — AI changes who writes the first draft, not who is answerable for the result.
6.Frequently asked questions
Are you saying not to use AI to write IFS Cloud automation?
No — using a model to draft a query or a first pass at logic is a legitimate time-saver. The point is that drafting and owning are two different jobs, and a generated draft still needs a named owner, a dry-run, and a review before it touches production.
What is the single biggest risk of AI-assisted automation on a live ERP?
An unscoped first run — code that was validated against a small test case behaving very differently the first time it processes the full history of a live table, with no rate limit or dry-run to catch it before it reaches real suppliers or customers.
How is this different from any other code review process?
It is not fundamentally different — it is a reminder that AI-generated code deserves the same review any custom ERP code gets, at a moment when its polished, instant appearance tempts teams to skip that step.
Is automation built this way update-safe?
Yes, provided the delivered rule — regardless of how the first draft was produced — is standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, with no core modification for the next release to 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.
Ask the 6am question before it asks itself
Whatever drafted the first version, a 30-minute call can help you scope the blast radius, the dry-run and the ownership before anything AI-assisted touches live purchase orders, suppliers or customers.
