---
title: "IFS Quick Reports vs Custom Fields vs Custom Events"
date: 2026-08-19
description: "A decision guide to IFS Cloud Quick Reports, Custom Fields and Custom Events: what each does well, update-safety, governance, and when to use which."
author: "Dariusz Mysliwiec"
categories:
  - name: "Blog"
    url: "https://www.ifs-erp.com/blog.md"
---

# IFS Quick Reports vs Custom Fields vs Custom Events

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](https://www.ifs-erp.com/blog/ifs-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, so they survive each R1/R2 release instead of breaking. That is the whole [Clean Core](https://www.ifs-erp.com/blog/clean-core-ifs-cloud-scm) 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

 1. **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.
2. **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.
3. **Over-using modifications**: jumping to server-side code when a Custom Field or Event would do. Every unnecessary modification is a future upgrade tax.
4. **Custom Field sprawl**: adding fields with no naming standard, owner or documentation until nobody trusts the data.
5. **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](https://www.ifs-erp.com/blog/automate-scm-processes-ifs-cloud).

 [See the SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack) [See the full offer](https://www.ifs-erp.com/offer)

  ## 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, because 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, because 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**: 18 years of hands-on IFS practice (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, so 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.

 [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call)