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, the tools and lifecycle feel different. The terms configuration and customisation are also used more formally in Cloud, although Apps 10 documentation and project teams did not always use one universal opposite terminology.

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 is worth understanding why things have changed. IFS Applications 10 is a tightly integrated Oracle application with generated PL/SQL business logic, the Windows-based IFS Enterprise Explorer (IEE), and Aurena as a web client. Oracle Forms belongs to earlier IFS generations, not the Apps 10 client architecture. Much—though not literally all—server business behaviour is generated or implemented in Oracle PL/SQL.

IFS Cloud retains the integrated Oracle/generated-server foundation while changing the web client, service exposure, tooling, deployment, and operating model. Projections provide OData/REST service contracts for the client and integrations, and Developer Studio uses declarative source models (including Marble client/projection source) alongside generated PL/SQL. Some platform capabilities are separate services, but it is misleading to describe the complete business application as independently deployable microservices.

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 generated custom-field storage for the logical unit
   • 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 generates/publishes the custom-field storage and extends relevant views (commonly through _CFT artefacts and CF$_ attributes in Apps 10, not a hand-managed column on the IFS base table)
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. These custom attributes were stored as metadata rather than baked into IFS source files, so they generally persisted through updates. Persistence was not compatibility, however: generated artefacts, pages, and any code that consumed the attributes still needed testing after an update.

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. Application-event attributes are substituted with ampersand tokens, so a typical Apps 10 pattern was:

IFS substitutes &ORDER_NO and &CUSTOMER_NO before executing the block; these string parameters therefore remain quoted. A colon-prefixed token would be treated as an unbound Oracle bind variable in this event-action mechanism. Here, My_Custom_API is a customer PL/SQL package developed and deployed under the Apps 10 database-change process, outside an IFS source build.

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
• IFS code generation and component lifecycle tooling did not enforce IFS coding standards on those standalone 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 governed source-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: A More Formal Terminology Split

Here's where things can get confusing for anyone coming from Apps 10: IFS Cloud uses configuration and customisation as explicit lifecycle categories.

In IFS Cloud:

• Configuration covers metadata-driven tailoring such as custom attributes, events and page configuration, transported through the configuration lifecycle.
• Customisation covers customer/partner source changes built with IFS development tooling and delivered as part of the customer solution.

Apps 10 already used terms such as Custom Objects for metadata-driven changes and customisation for source-layer work, while project teams often used “customisation” more loosely for both. Cloud did not universally swap two stable Apps 10 definitions; it made the delivery boundary more explicit. In migration workshops, say which lifecycle you mean rather than relying on the word alone.

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

Configuration — Metadata-driven changes made through IFS Cloud Web in a use-place environment. No source build is required; transport is still governed through ACP/configuration tooling.

Customisation — Customer/partner source changes developed with IFS tooling and built into a supported delivery. This is a last-resort option when standard behaviour, configuration, workflow, and governed external extension patterns cannot meet a justified requirement cleanly.

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. Its metadata-driven work is performed through IFS Cloud Web, does not require an IFS source build, 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 can add buttons/actions to supported Cloud pages. The command is the client interaction; state-changing logic belongs in a configured or source-developed server action. Do not assume arbitrary PL/SQL can be embedded in every command or that a private package method is safe to expose.

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, a source customisation should not silently depend on a field that exists only as separately transported configuration metadata. Model source-owned dependencies in the source solution, or give the configuration dependency an explicit supported contract and lifecycle. Cross-layer dependencies can be valid, but they must be deliberate and deployed in the correct order.

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).

Where Configuration-Based Logic Becomes Risky

Configuration is a supported fit for many attributes, events, notifications, commands, and narrowly scoped rules. It becomes a poor fit when transactional logic grows complex or when separately transported configuration becomes an implicit dependency of source customisation. The main risks are:

1. Update risk — Embedded PL/SQL in event actions is not managed like generated source. Across release and service updates, the SQL may call an API whose signature or semantics changed without a compile-time check in the customer solution.

2. Weaker code-review path — SQL embedded in event actions is stored as configuration text. An ACP export can be version-controlled and reviewed, but it does not receive the same generation, compile-time checks, or unit-test structure as source-owned code.

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: Source Customisations (The Last-Resort Code Path)

The Customisation approach in IFS Cloud is source-level development using IFS Developer Studio and the customer-solution build lifecycle. It is not the automatic answer to every non-trivial rule. Evaluate standard application capability, configuration, workflow and governed external extension first; use source when a justified requirement needs a supported in-process extension point and the recurring update cost is accepted.

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 — layers a supported change around/onto the lower-layer element and retains lower-layer behaviour through the generated super call where applicable.
• 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, change the Marble projection model and implement generated server scaffolding in the layered .plsql source supplied by the target model/release. A universal hand-written .plsvc format should not be assumed.
   • For client files, change only supported model elements. Whether an element can be overridden or must be overtaken is defined by its generated reference/tooling, not by a blanket “all commands” rule.

6. Generate and validate — run the code generator, build the affected customer solution, and deliver it through the supported development route. Do not assume an IFS-managed Cloud database is directly deployable from the IDE.

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 and generated implementation markers. Do not invent a procedure signature from a projection/action name. The reliable pattern is:

This is a real layering shape, not the release action itself. Use Developer Studio to create the exact source fragment and signature, retain super for an override, call public entity APIs rather than private __ methods or _TAB DML, and let the enclosing framework own commit/rollback.

Exposing Custom Logic via Projections

Custom PL/SQL must be exposed through a projection when the IFS Cloud Web client or an external REST consumer needs to invoke it. Backend-only logic called by a supported Database Task, event, workflow, or another server implementation does not need a projection merely for the sake of having one.

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 publishes regular release and service updates; the customer's exact adoption, deferral, and support timetable depends on deployment and service agreement.

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 can be justified for complex, in-process 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 — IFS Cloud configuration covers many of the same requirements through custom attributes, events, page configuration and commands. Do not assume a one-to-one conversion: review event timing, page support, security, and every called API, then transport the accepted configuration through ACPs.

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. Inventory direct DML, private APIs, files, network calls, scheduler dependencies, and event transaction behaviour. Retain justified server logic in a supported customer component, replace it with standard/configuration/workflow where possible, and move genuinely external responsibilities behind governed APIs. Ad-hoc database packages are not an acceptable deployment path in IFS-managed Cloud.

---

Key Takeaways

1. Name the layer, not just the terminology. Say “in-application configuration” or “source customisation” so the delivery and update implications are clear.

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. Customer-layer source gives controlled implementation points, but adopted release and service updates require impact and regression review.

4. Make cross-layer contracts explicit. A source customisation must not silently depend on separately transported configuration metadata. Prefer one owning lifecycle; where a supported cross-layer dependency is necessary, document it, validate it, and enforce deployment order.

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 APIs are a legitimate extension boundary. Projections can avoid source changes for integrations and external capabilities, but they are versioned contracts rather than automatically “upgrade-safe”; discover and test them in every target release.

---

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