Deutsch (Deutschland) 
Polski (PL) 
Independent IFS Cloud practice · Supply Chain
IFS Custom Events explained: automate your supply chain without touching the core
Key takeaways
- IFS Custom Events let you react to something happening in IFS Cloud (a PO saved, a receipt posted) without changing core code.
- An event is a trigger plus one or more actions; PL/SQL is available for the cases plain configuration cannot cover.
- Unlike a core modification, a Custom Event is update-safe, because it is carried forward by each release.
- The real risks are alert storms and performance; dry-run, frequency caps and a test week contain both.
- The SCM Automation Pack is twelve production-ready Custom Event automations you can buy and tune.
Most supply-chain controls in IFS Cloud still run on someone remembering to look. A buyer checks for unconfirmed orders when they have time; a planner spots a stock-out after it has already happened. IFS Custom Events move that watching into the system itself, and they do it without a single change to the core, so nothing breaks at the next upgrade. This article explains what Custom Events are, how they differ from modifications, where PL/SQL fits, the risks worth respecting, and a worked example you can picture on your own data.
1.What are IFS Custom Events?
A Custom Event is a standard IFS Cloud mechanism that watches for a defined change in the database and runs logic when it happens. You are not writing a background program; you are declaring, inside the application, “when this occurs, do that.” The “this” is a trigger: a row inserted, updated or deleted on a table you choose, optionally narrowed by a condition. The “that” is one or more event actions.
Because Custom Events live in the Extensibility Framework rather than in modified standard code, they are the backbone of a Clean Core build. If that term is new, Clean Core in IFS Cloud explains why the distinction decides your upgrade cost.
2.How do Custom Events differ from modifications?
Both can achieve the same automation. Only one survives an upgrade cleanly. The difference is where the logic sits:
| Aspect | Custom Event | Core modification |
|---|---|---|
| Location | Extensibility layer, outside the core | Edited standard package or view |
| Upgrade behaviour | Carried forward and re-validated | Overwritten; must be re-applied |
| Built by | Consultant or trained key user, in the UI | Developer with core source access |
| Rollback | Disable the event: instant, contained | Re-patch and re-test the core |
| Update-safe? | Yes | No |
A Custom Event you no longer want is switched off in seconds. A core modification you no longer want is a project. That reversibility is half the reason to prefer events.
3.Triggers, actions and where PL/SQL fits
Every Custom Event has the same anatomy. Understand these three parts and you can read any automation in the pack:
- Trigger: the table and operation you watch (for example, a purchase order line updated), plus an optional condition so the event fires only when it matters.
- Action is what happens next: send an email or alert, start a Workflow, set a Custom Field, or call server logic.
- PL/SQL is used inside an action when a rule needs real logic: look up a tolerance, compare values, decide who to notify. It runs in the event, not in the core.
Most scenarios need only a trigger, a condition and a notify action. PL/SQL is the exception you reach for when the decision is genuinely conditional, and even then it stays update-safe, because it is attached to the event rather than welded into a standard package. For the wider picture of chaining events with Workflows, see how to automate SCM processes in IFS Cloud.
4.What are the risks and the safeguards?
Custom Events are safe by mechanism, but not automatically safe by design. Two failure modes are worth respecting, and each has a matching control:
| Risk | What goes wrong | Safeguard |
|---|---|---|
| Alert storm | A broad trigger fires hundreds of emails; people stop reading them | Tight conditions plus a frequency cap per scenario |
| Performance | Heavy logic on a high-volume table adds load to every transaction | Narrow triggers, lean PL/SQL, run against volume in test |
| Untested behaviour | An event does the wrong thing in production first | Dry-run mode and a mandatory test week |
Dry-run is the key habit: the event evaluates and logs what it would do without sending or writing anything. You watch a week of real transactions flow through it, confirm the volume and the targets are right, then switch it live. Every scenario in the pack ships with dry-run and a frequency cap for exactly this reason.
5.Worked example: unconfirmed PO escalation
A common gap: purchase orders sent to suppliers but never acknowledged. Nobody owns the follow-up, and the first sign of trouble is a late delivery. Here is the same control as a Custom Event, step by step:
- Trigger: watch purchase order lines; fire when a line is still in an unconfirmed state.
- Condition: only when the order date is older than your threshold (say, three working days) and the value is above a floor worth chasing.
- PL/SQL: resolve the responsible buyer from the order, and skip any supplier flagged as exempt.
- Action: email that buyer, and after a second threshold, escalate to the purchasing lead.
- Frequency cap: at most one reminder per order per day, so a slow supplier never floods an inbox.
- Dry-run week: log intended emails for a week, confirm the list and the counts, then go live.
Nothing in that sequence touches the Purchasing core. It is a trigger, a condition, a little PL/SQL and a notify action, and it keeps working after every upgrade.
6.Why are Custom Events update-safe?
Because IFS treats the Extensibility Framework as a supported layer that upgrades must preserve. Your event is registered as an extension against standard tables and projections; when a new track arrives, that extension is carried forward and re-validated rather than overwritten. There is no modified core to re-patch, so the upgrade job for your automations shrinks to a short checklist: list them, confirm each still binds, dry-run each once, sign off. That is the whole point: the automation earns its keep every day and costs you almost nothing at upgrade time.
7.Frequently asked questions
Do IFS Custom Events modify the core?
No. Custom Events live in the Extensibility Framework and react to standard database changes from outside the core. That is why they are update-safe: an upgrade carries them forward and re-validates them instead of overwriting them, unlike an edited standard package.
When do I need PL/SQL in a Custom Event?
When plain configuration cannot express the rule, for example looking up a tolerance, comparing values, or deciding who to notify. The PL/SQL runs inside the event action, so it stays update-safe. Most scenarios need only a trigger, a condition and a notify action.
How do I stop Custom Events from causing alert storms?
Keep triggers narrow with tight conditions, and put a frequency cap on each scenario so a single record cannot generate repeated alerts. Then prove it in dry-run mode across a real test week before go-live, watching the volume and the recipients before anything is sent.
Can Custom Events slow down IFS Cloud?
They can if a heavy trigger fires on a high-volume table on every transaction. The fix is design discipline: narrow the trigger, keep the PL/SQL lean, and test against realistic volume before go-live. Well-scoped events add negligible load.
8.About the author
Dariusz Myśliwiec: 18 years of hands-on IFS practice (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.
Put the watching in the system, where it belongs
Tell me where your supply chain loses time to manual checking today. On a 30-minute call I’ll show you which Custom Event scenarios pay for themselves first, all update-safe and all dry-run tested before anything goes live.
