Adding Business Logic in IFS: Apps 10 vs IFS Cloud

If you've worked with IFS Applications 10 and are now looking at IFS Cloud — or you're an IFS developer trying to understand how the development model has shifted — you've probably noticed that something feels fundamentally different. The tools look different. The terminology is different. And confusingly, IFS has managed to swap the meaning of the words "customisation" and "configuration" between the two versions.

This article breaks down exactly how business logic and application extensions work in both platforms, why the approach has changed, and what that means for developers and organisations moving from Apps 10 to Cloud.

---

A Quick Primer on Architecture

Before diving into the development approaches, it's worth understanding why things have changed. IFS Applications 10 is built on a monolithic architecture — a tightly integrated suite of Oracle PL/SQL packages, Oracle Forms (in older versions), and the Aurena web client (introduced in Apps 9/10). All the application logic lives in Oracle Database procedures and packages. Extensions hook into that layer.

IFS Cloud takes a microservices approach, breaking the application into smaller, independently deployable services. The front end is a modern Aurena web client built on TypeScript. The back end is still Oracle PL/SQL, but structured around a formal layered development model using IFS's own Marble modeling language for projections (the API layer between database and UI). OData and REST APIs are first-class citizens.

This architectural shift is the root cause of every difference you'll encounter when trying to add business logic.

---

IFS Apps 10: The "Customising" Approach

In IFS Applications 10, extending the application without touching IFS source code was handled through what most people called customisation (and what IFS's own documentation often called "custom objects"). This was entirely the right term at the time — you were customising IFS to fit your business.

The tooling lived primarily in IFS Enterprise Explorer (the Windows thick client) and the Solution Manager area, with deeper work handled by IFS Developer Studio.

Custom Fields (Custom Attributes)

The most common starting point for capturing additional data was adding a Custom Field to an existing IFS page.

The process worked like this:

1. Open IFS Enterprise Explorer and navigate to Solution Manager → Custom Fields
2. Search for the Logical Unit (LU) corresponding to the page where you wanted the new field (e.g., CustomerOrder for sales orders)
3. Add a new attribute record using the custom attribute wizard, choosing from three types:
   • Persistent — stored in the database, tied to a real column added to the table
   • Read Only — computed/derived, not stored directly
   • Local — session-scoped, not persisted
4. Approve the attribute and the logical unit
5. Publish the logical unit — this physically alters the database to add the column and regenerates the relevant views
6. Navigate to the target page, open the Column Chooser or use Layout Functionality to drag the new field onto the form
7. Use Base Profiles to distribute the layout change to all users

The whole process could be completed by a functional consultant or administrator — no access to IFS source code required. Importantly, these custom attributes survived IFS upgrades because they were stored as metadata within the IFS database itself, not baked into source files.

Custom Events and Event Actions

Custom Fields captured data. Custom Events added behaviour — the ability to execute logic when something happened in IFS.

IFS Apps 10 had two categories of events:

Application Defined Events were pre-wired by IFS R&D into the PL/SQL logic. They fired at predictable moments (e.g., "Customer Order Released", "Purchase Order Created"). You couldn't create these — but you could attach actions to them.

Custom Defined Events were database-trigger-based events that customers could create themselves. You'd point one at a specific database table, and it would fire on INSERT, UPDATE, or DELETE operations against that table.

Once you had an event, you'd attach Event Actions, which defined what to do when it fired. Action types included:

• E-Mail — send a notification email to one or more recipients, with support for dynamic values from the event payload
• Execute Online SQL — run an arbitrary SQL or PL/SQL statement in the current database. This was the key hook for custom business logic
• Application Message — route a structured message through IFS Connect for integration scenarios
• Task — create a to-do item in a user's task panel inside Enterprise Explorer
• Start Workflow — call an external web service, typically a workflow engine
• Streams Message — publish to IFS Streams for notification purposes

The Execute Online SQL action type was the workhorse for business logic. A typical pattern was:

Where MyCustomPackage_ was a custom PL/SQL package developed and deployed manually to the Oracle database — outside of the IFS build process.

This approach was powerful and accessible to skilled consultants without needing a full IFS development environment. But it had limitations:

• The PL/SQL was embedded as free-text SQL in the event action record — not in version-controlled source files
• Custom packages deployed directly to the database existed outside the IFS component model and weren't tracked by the IFS lifecycle system
• Debugging was difficult — errors surface as runtime database exceptions
• There was no formal way to enforce IFS coding standards on custom packages
• On upgrade, these packages persisted in the database but might call IFS APIs that had changed

Application Configuration Packages (ACPs)

To provide some lifecycle management for custom objects, IFS Apps 10 had Application Configuration Packages (ACPs). These allowed you to group custom fields, events, event actions, custom menus, and other objects into exportable packages. ACPs could be:

• Exported from a source environment as XML
• Imported into target environments (e.g., test → production)
• Version-controlled in a source code repository (though this required manual discipline)

ACPs were the closest thing Apps 10 had to deployment pipelines for configuration-level changes. They worked reasonably well for simple custom objects, though managing complex interdependencies between ACPs across multiple environments was a frequent source of headaches.

Developer Studio Customisations in Apps 10

For more invasive changes — altering how an IFS page behaved, adding new pages, or extending IFS PL/SQL packages with new logic — Apps 10 developers used IFS Developer Studio. This involved:

• Working directly with IFS source code files in a layered development model
• Creating "-Cust" files that overrode or extended base IFS functionality
• Running a build process to generate deployable packages
• Managing these customisations through the IFS Component Lifecycle System

This was the "proper" customisation path, used by IFS partners and larger customers with dedicated development teams. It was more powerful than custom events but also far more costly to maintain across upgrades, because any changes to IFS source that overlapped with your overrides needed to be manually reconciled.

---

IFS Cloud: The Great Terminology Swap

Here's where things get confusing for anyone coming from Apps 10: IFS Cloud inverts the terminology.

In IFS Cloud:

• What was called a Customisation in Apps 10 (custom fields, custom events, no-code extensions) is now called a Configuration
• What was called a Customisation in Developer Studio (editing source code, formal build process) is now called a Customisation

This is not a typo. IFS genuinely swapped the words. The IFS community has noted the confusion — and official documentation even includes warnings about it.

To be precise about what each term means in IFS Cloud:

Configuration — Changes made via the Aurena web client, in the "Use Place" (your live/config environment). No build process required. Equivalent to what Apps 10 called customising with custom objects.

Customisation — Code changes made in the "Build Place" using IFS Developer Studio. These modify IFS source code directly and are compiled into deployable packages. This is the recommended approach for meaningful business logic in IFS Cloud.

Let's look at each in detail.

---

IFS Cloud: Configurations (The Low-Code Path)

The Configuration approach in IFS Cloud is the direct successor to Apps 10's custom objects approach. It's done entirely through the Aurena web interface, doesn't require access to source code, and is aimed at functional consultants and administrators.

Custom Fields and Attributes

Custom Fields work similarly to Apps 10, but the interface is now inside the Aurena web client rather than Enterprise Explorer. The underlying mechanics are the same:

• Navigate to a logical unit in the configuration tooling
• Add a persistent, read-only, or local attribute
• Approve and publish
• Use page configuration to add the field to the UI

One notable improvement is that the Aurena interface is more accessible than Enterprise Explorer's solution manager, and the configuration experience is more integrated with the rest of the application.

Custom Events and Custom Commands

Custom events still exist in IFS Cloud under the Configuration umbrella. They work similarly to Apps 10 — attaching actions (email, execute SQL, etc.) to database triggers or application-defined events.

Custom Commands (formerly Custom Menus in Enterprise Explorer) allow you to add buttons and actions to Aurena pages, with PL/SQL execution embedded in the command definition.

The official IFS documentation notes that this pattern — using Custom Events with embedded PL/SQL to call Custom Utility Packages — is a "typical usage" for customer-specific business logic under the Configuration approach. However, it also flags this as something to be careful about, particularly:

"Do not make a customization containing business logic dependent on a custom attribute added using configuration. Instead add that attribute as part of the customization."

— IFS Cloud Customization Best Practices

In other words, if you need custom business logic that depends on a custom field, you should keep everything in the same layer — either all in Configurations or all in Customisations. Mixing them creates fragile dependencies.

Page Configuration

One area where IFS Cloud's Configuration approach genuinely improves on Apps 10 is Page Configuration — the ability to rearrange, hide, or add elements to Aurena pages without any code. In Apps 10 this was done through layout profiles in Enterprise Explorer, which worked but was clunky. In IFS Cloud, the page configuration tooling is more visual and easier to use.

Application Configuration Packages in IFS Cloud

ACPs still exist in IFS Cloud and still serve the same purpose — packaging configuration objects for transport between environments. The process is:

1. Make your configuration changes in the Config environment
2. Group your custom objects into an ACP
3. Export the ACP as XML
4. Import to target environments (test, production)
5. Optionally store the exported XML in source control

The ACP structure in IFS Cloud is more formally defined than in Apps 10, with clearer guidance on where ACP files should live within the component folder structure (<component>/server/appconfig or <component>/nobuild/appconfig).

Why Configurations Are "Not Recommended" for Business Logic

Despite Configurations being more accessible, IFS's own guidance is clear: for meaningful business logic, Configurations are not the recommended path. The reasons:

1. Upgrade risk — Embedded PL/SQL in event actions and custom commands is not managed by the IFS build system. When IFS releases updates (twice yearly in the Cloud evergreen model), your custom SQL may call IFS APIs that have changed, with no automated compatibility checking.

2. No formal code review path — SQL embedded in event actions is stored as text in database tables, not in source files. It can't easily be code-reviewed, linted, or unit tested.

3. Limited business logic complexity — Event actions work well for simple triggers and notifications. Complex business logic — conditional flows, multi-step operations, rollback scenarios — quickly become unmaintainable in embedded SQL.

4. Mixing layers is risky — If Configuration-level custom fields become dependencies for business logic, you've created an implicit coupling that's hard to document and dangerous to refactor.

---

IFS Cloud: Customisations (The Recommended Path)

The Customisation approach in IFS Cloud is source-code-level modification using IFS Developer Studio. This is what IFS recommends for any non-trivial business logic requirement.

The Build Place vs The Use Place

A key concept in IFS Cloud development is the distinction between two "places":

• Build Place — where Customisations are developed. This is a development environment with access to IFS source code, a Build Home (the compiled IFS source), and IFS Developer Studio. This is where code is written, compiled, and packaged.

• Use Place — where the application runs. This is what users interact with. Customisations are deployed here from the Build Place. Configurations are also made here.

This separation is more formal than anything in Apps 10 and reflects IFS Cloud's enterprise-grade deployment model.

IFS Developer Studio and the Layered Development Model

IFS Cloud uses a layered development model. At the bottom is the Core layer — IFS's own source code. Above that is an Extension layer (used by IFS partners building vertical solutions). Above that is the Customisation layer — where customer-specific changes go.

Each layer can Override or Overtake elements from the layer below:

• Override — replaces or augments specific elements. The customisation is merged with the underlying layers during code generation, so you only need to specify what changes.
• Overtake — completely replaces an element. No merging occurs. Used when an override is insufficient.

The workflow for creating a Customisation in IFS Developer Studio:

1. Set up the Build Home — this is the compiled IFS source that serves as your base. It determines the target version for the code generator.

2. Create a Customisation Project in Developer Studio, pointing at the Build Home.

3. Locate the item to customise in the Build Home — e.g., a projection file (CustomerOrder.projection) or a client file (CustomerOrder.client).

4. Right-click → "Customize This" — Developer Studio creates an empty -Cust version of the file (e.g., CustomerOrder-Cust.projection). This is where your customisation lives.

5. Edit the -Cust file:

   • For projections, a .plsvc file is attached containing the PL/SQL that backs the projection's Actions and Functions. Add @Override or @Overtake annotations to modify specific methods.
   • For client files (the Aurena UI), modify the Marble markup to add fields, buttons, or change behaviour. Pages and lists are typically overridden; commands must be overtaken and fully rewritten.

6. Generate and deploy — run the code generator to compile your changes and deploy to the development database. Changes are immediately visible in Aurena.

7. Test in Aurena.

8. Build the deliverable — when ready for deployment, build the customisation into a deployable package using the Build Home's code generator.

9. Deploy to Use Place — the -Cust files are merged with the base IFS files during the pre-installation build process, and the result is deployed.

Writing Business Logic in PL/SQL

The PL/SQL side of a Customisation follows IFS coding standards. Rather than free-text SQL in event actions, you're writing proper IFS-style packages. A simple override of a projection's action might look like:

The super() call invokes the original IFS implementation, giving you clean before/after hooks without having to rewrite the entire method.

Exposing Custom Logic via Projections

One of the most important aspects of IFS Cloud Customisations is that any custom PL/SQL logic must be exposed through a projection to be accessible from the Aurena client or from external APIs.

In Apps 10, a custom PL/SQL package could be called directly from an event action's embedded SQL. In IFS Cloud, the recommended path is:

1. Write your custom PL/SQL package using IFS Developer Studio (so it's part of the build process and follows IFS standards)
2. Create or customise a projection (.projection file) to expose Actions or Functions that call your PL/SQL
3. Modify or create a client (.client file) to surface those actions in the Aurena UI

This separation of concerns — database logic in PL/SQL packages, API exposure in projections, UI in clients — is more structured than Apps 10's approach and makes for more maintainable code.

Upgrade Implications and the Evergreen Model

The biggest challenge with IFS Cloud Customisations is managing them through updates. IFS Cloud operates on an evergreen model with twice-yearly releases, meaning your production environment receives new IFS functionality regularly.

When a new IFS update arrives, any -Cust files that override or overtake elements in the Core layer need to be reviewed using the Update Analyzer tool in Developer Studio. This tool flags:

• Overrides where the underlying Core implementation has changed (your customisation may no longer apply correctly)
• Overtakes where the underlying code has been significantly refactored (your overtaken version may now be missing new functionality)

This is not a trivial maintenance burden. Every customisation becomes a recurring cost — not just to build initially, but to validate against each IFS update. IFS's own documentation is frank about this:

"A customisation should only be used as very last resort as it causes implications when upgrading and taking patches."

— IFS Cloud Technical Documentation (23R1)

This caveat doesn't mean Customisations are wrong — they're necessary for complex business logic. But it explains why IFS's official preference is to use Configurations where possible, and to minimise the footprint of Customisations to reduce upgrade overhead.

---

Side-by-Side Comparison

---

The Practical Reality

For organisations moving from Apps 10 to IFS Cloud, the practical impact depends heavily on how they used Apps 10.

If your Apps 10 extensions were mostly custom fields, custom events, and custom menus — the Configuration path in IFS Cloud covers this. The mechanics are familiar, the Aurena interface is cleaner than Enterprise Explorer, and ACPs still provide lifecycle management. Plan to review and recreate your custom objects in the new environment, but don't expect a fundamentally different approach.

If your Apps 10 extensions involved Developer Studio customisations — you're already in familiar territory with IFS Cloud's Customisation approach. The layered model is more formalised than before, and the Marble projection layer is new, but the core concepts of overrides and overtakes are consistent.

If you relied heavily on custom PL/SQL packages called from event actions — this is the area with the most friction. In Apps 10, deploying a PL/SQL package directly to the Oracle database worked well enough. In IFS Cloud, IFS strongly recommends that custom PL/SQL packages go through Developer Studio so they follow the component model and are tracked by the build system. Custom packages deployed ad-hoc to the database can be made to work but won't appear in the IFS dictionary (which powers things like the Database Task selector) and won't be managed through the standard lifecycle.

---

Key Takeaways

1. The terminology is inverted. What Apps 10 called "customising" is now "configuring". What Apps 10's Developer Studio approach produced is now officially called "customising". Know which one you mean before any conversation with an IFS consultant or partner.

2. Configurations are accessible but limited. Custom fields, events, commands, and page layouts via the Aurena UI are great for functional extensions. They're not the right tool for complex, conditional business logic that needs proper error handling and testing.

3. Customisations are powerful but carry ongoing cost. Editing IFS source in Developer Studio gives you full control, but every update from IFS requires a compatibility review. In IFS Cloud's evergreen model, that's at least twice a year.

4. Keep your layers clean. Don't mix Configuration-level custom attributes with Customisation-level business logic. Pick a lane for each requirement and stay in it.

5. The evergreen model changes the calculus. In Apps 10, upgrades were major multi-year projects — you could carry a heavy customisation footprint for years before it became a problem. In IFS Cloud, updates arrive continuously. Every Customisation is a recurring maintenance item. Minimise the footprint where you can.

6. IFS Cloud's APIs are a legitimate alternative. For integrations and some business logic scenarios, IFS Cloud's OData and REST API layer (via projections) provides a clean, upgrade-safe way to build extensions without modifying source code at all. It's worth evaluating this path before reaching for Developer Studio.

---

Further Reading

• IFS Cloud Tailoring Guide — the official reference for both Configurations and Customisations
• IFS Apps 10 Development Documentation — covers Developer Studio and the Apps 10 development model
• IFS Community — Customization vs Configuration — a frank community discussion on the terminology
• IFS Community — Upgrading from Apps 10 to Cloud — real-world experiences from the IFS community