Choose an integration approach

26R1 reference · Documentation-based tutorial draft · Not executed in IFS

Integration learning center

Outcome and prerequisites

Decide, before writing any code, which integration mechanism fits a stated requirement. You need a written description of the trigger, the data, and the systems involved; no IFS access is required for this planning exercise.

The concept

IFS Cloud exposes several different mechanisms for exchanging data with other systems. They solve different problems, and choosing the wrong one tends to show up much later as a reliability or maintenance problem rather than an immediate error. Ask these questions in order:

1. Does an external system need to call IFS directly, on demand? Use a projection API (REST, OData-style). This is the default for synchronous reads and small, targeted writes initiated from outside IFS. Start with API discovery.
2. Does the logic belong inside IFS, reacting to something that happens in IFS? Use a workflow (Business Process Automation). Workflows validate, enrich, and orchestrate IFS-side events, and can call REST services as one step in that process. See the workflow learning center.
3. Is this a message-oriented exchange with routing, transformation, or multiple external endpoints, especially where IFS itself should originate or distribute the message? This is the territory of IFS Connect. Treat this as its own topic; do not assume it behaves like a projection API.
4. Is the exchange high-volume, batch, or with a system that cannot call an API at all? Use scheduled file exchange (CSV/XML/JSON contracts on a transport your environment supports).
5. Does no existing API expose the operation you need? Build a custom projection service. See connect a projection function before assuming you must write one from scratch — confirm no standard API already covers it.

These are not mutually exclusive. A realistic integration often combines them: a projection API for on-demand reads, a workflow for validation at the point of entry, and file exchange for a nightly reconciliation batch.

A worked scenario

A partner system needs to know when a fictional handover record changes status, and occasionally needs to push a correction back into IFS. The status notification is IFS reacting to its own event — a workflow with a REST task is a reasonable starting point (see outbound calls from a workflow). The occasional correction is the partner system calling IFS on demand — a projection API write is the reasonable starting point (see writing data). Treating both needs as “one integration” tends to produce a design that is harder to reason about than treating them as two small, well-scoped ones.

Work through it

1. Write down, in one sentence, who initiates each data exchange: IFS, or the external system.
2. For each exchange, classify it as on-demand/synchronous or batch/scheduled.
3. Match each exchange to one row of the decision list above.
4. Note any exchange you are unsure about — that uncertainty is the actual research task, not a reason to guess.

Try it yourself

A finance system sends IFS a nightly file of approved supplier payments and expects IFS to expose year-to-date spend on demand for a dashboard. Classify both directions.

See a suggested answer

The nightly file is external-to-IFS, batch, high volume: scheduled file exchange fits. The on-demand dashboard read is external-to-IFS, synchronous, targeted: a projection API read fits, most likely through query shaping with filtering by date range. Neither direction obviously needs IFS Connect or a workflow, but confirm the actual file transport and the actual API’s filter support before committing to this design.

Check your understanding

Assuming that because IFS Connect can theoretically carry any of these exchanges, it is always the safest default. A mechanism built for routing and transformation between multiple systems adds real operational cost when a direct projection API call would have been simpler and easier to support.

Expected result: a written classification for each exchange in your scenario, with unresolved questions listed explicitly.

Cleanup: none; this exercise changes no IFS data.

Sources and review status

IFS Cloud technical documentation, extensibility and integration overview. Source consulted 2026-09-23. The scenario and exercise are original fictional examples. This concept draft has not been reviewed by an IFS specialist or executed in an IFS environment. IFS Connect mechanics are intentionally described at a high level here pending a dedicated, source-verified guide.