Independent IFS Cloud practice · Extensibility
IFS Quick Reports vs Custom Fields vs Custom Events: when to use what in IFS Cloud
IFS Quick Reports, Custom Fields and Custom Events are the three workhorses of the IFS Cloud Extensibility Framework. Reach for the wrong one and you get a report that times out, a field nobody trusts, or an automation that fires when it should not. Reach for the right one and you extend IFS without touching the core.
Key takeaways
- Quick Reports read data out — fast SQL-based lists and extracts, but no logic and no data capture.
- Custom Fields store new data on existing records — when standard IFS has no place to put your attribute.
- Custom Events do something when data changes — alerts, workflows and automation triggered by inserts or updates.
- All three are update-safe when used inside the Extensibility Framework; a full modification is the last resort, not the first.
- The common mistakes are Quick Reports on volatile views and over-using modifications where a Custom Field or Event would do.
Most IFS Cloud requests come dressed as “can we just add a report / a field / a little automation?” The tool you pick decides whether that request stays update-safe or turns into an upgrade tax. Here is a clear way to choose.
1.What is each tool, in one line?
- Quick Report — a saved SQL query surfaced in the client, for reading and extracting data. It answers “show me a list of…”.
- Custom Field — a new attribute added to an existing entity, stored and shown by IFS. It answers “where do we record…?”.
- Custom Event — a trigger that watches for an insert or update and fires an action or workflow. It answers “when X happens, do Y”. See Custom Events explained.
They are complementary, not competing. A mature solution often uses all three: a Custom Field to capture data, a Custom Event to react to it, and a Quick Report to read it back out. The skill is knowing which job belongs to which tool.
2.What is each good and bad at?
| Tool | Good at | Bad at / avoid |
|---|---|---|
| Quick Reports | Fast lists, extracts, ad-hoc data pulls; quick to build; no deployment | No logic or automation; no data capture; heavy queries on volatile views hurt performance |
| Custom Fields | Storing a new attribute on a standard record; visible, searchable, reportable | Not for behaviour or calculations; sprawl if ungoverned; can bloat pages and APIs |
| Custom Events | Alerts, approvals, workflow and automation on data changes; reacts in real time | Not for reporting; poorly scoped events fire too often; need dry-run and frequency caps |
3.Decision matrix: which tool for which need?
Match the need on the left to the recommended tool on the right.
| Your need | Recommended tool | Why |
|---|---|---|
| See a list of open POs past due | Quick Report | Read-only extract; no logic needed |
| Record a custom “inspection status” on a part | Custom Field | New attribute on a standard record |
| Alert a buyer when a supplier price jumps | Custom Event | Act when data changes, in real time |
| Email a planner nightly with low-stock parts | Quick Report (scheduled) | Recurring read-out, no per-record trigger |
| Flag & hold an order that breaks a rule | Custom Event | Condition + action on the transaction |
| Capture data and react to it | Field + Event | Store the attribute, then trigger on it |
| Complex server-side logic across entities | Modification (last resort) | Only when the framework genuinely cannot; keep it Clean Core |
Rule of thumb: reading → Quick Report; storing → Custom Field; reacting → Custom Event. A modification is what you reach for only when none of those three can do the job.
4.Update-safety, performance and governance
All three tools live inside the Extensibility Framework, so all three are update-safe by design — they survive each R1/R2 release instead of breaking. That is the whole Clean Core argument: extend IFS without editing it. But update-safe is not the same as consequence-free.
- Performance — Quick Reports run live SQL; a heavy query on a busy or volatile view can slow the client for everyone. Scope, filter and, where possible, target stable views.
- Field sprawl — ungoverned Custom Fields multiply, bloat pages and APIs, and leave nobody sure which field is authoritative. Name, document and own them.
- Event storms — a broadly scoped Custom Event can fire far more often than intended. Use conditions, a dry-run week and a frequency cap.
- Governance — who can create these, who reviews them, and where they are documented matters as much as the build. Ungoverned extensibility becomes its own kind of technical debt.
5.Common mistakes to avoid
- Quick Reports on volatile views — building heavy extracts on high-churn or derived views. They are slow, they can lock, and the numbers move under you. Prefer stable, well-filtered sources.
- Using a report where you needed an event — a nightly report cannot stop a bad transaction; by the time it runs, the price already posted. If timing matters, use a Custom Event.
- Over-using modifications — jumping to server-side code when a Custom Field or Event would do. Every unnecessary modification is a future upgrade tax.
- Custom Field sprawl — adding fields with no naming standard, owner or documentation until nobody trusts the data.
- Un-capped events in production — going live without a dry-run week or frequency cap, then drowning users in alerts on the first bulk load.
Get these choices right and extensibility stays a strength. Get them wrong and you rebuild the same upgrade tax the framework exists to prevent. For the wider pattern of doing this well, see how to automate SCM processes in IFS Cloud.
6.Frequently asked questions
What is the difference between a Quick Report and a Custom Event in IFS Cloud?
A Quick Report reads data out — it is a saved SQL query for lists and extracts, with no logic. A Custom Event reacts to data changing — it watches for an insert or update and fires an alert, workflow or action. Reporting is passive and on-demand; events are active and real-time.
When should I use a Custom Field instead of a modification?
Use a Custom Field whenever you only need to store a new attribute on a standard record — it is update-safe and needs no core change. Reserve a modification for genuine server-side logic the Extensibility Framework cannot express. Reaching for a modification first is the most common way to create an upgrade tax.
Are Quick Reports, Custom Fields and Custom Events update-safe?
Yes. All three are part of the IFS Cloud Extensibility Framework and are designed to survive each R1/R2 release without breaking. That is the Clean Core principle: extend IFS rather than edit it. Governance still matters — performance, field sprawl and event scope are your responsibility, not the framework’s.
Why are Quick Reports on volatile views a problem?
Quick Reports run live SQL against the database. On a high-churn or heavily derived view, a large query can be slow, can contend with transactional work, and can return numbers that shift while it runs. Target stable, well-filtered sources, and if you need to act on a change rather than list it, use a Custom Event instead.
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. Based in Kraków, delivering remotely across Europe and globally as an independent practice — you talk to the consultant who builds it.
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.
Not sure which tool your requirement needs?
Bring me the request — a report, a field, a bit of automation — and on a 30-minute fit call I’ll tell you which update-safe tool fits and what it costs to build. No modification unless it is genuinely the only way.
