How to close functional gaps in IFS Cloud without core modifications

The instinct when IFS does not do something is to change IFS. But core modifications are the classic source of upgrade pain: every change you bury in the core is something you have to re-test and re-apply later. The better pattern is to close the gap on the outside, through the APIs IFS already exposes.

Build on the surface, not in the core

IFS Cloud publishes OData REST projections for exactly this reason. An app that reads and writes through projections — with proper authentication, ETags and bound actions — gets the job done without touching the core. Users get a tailored tool; the platform stays standard.

This applies to the whole long tail of gaps:

• Focused capture forms that write back to IFS
• Reports and dashboards on live IFS data
• Integrations to other systems through OData
• Approval and action apps that call IFS bound actions

Keep security where it belongs

Closing gaps on the outside does not mean working around security. Apps should authenticate through IFS and honour the IFS permission model, so a user in a custom app can only do what they could do in IFS. Self-hosting keeps the data in your environment.

Make it fast enough to be worth it

The reason teams reach for modifications is often speed: a quick core tweak feels faster than a proper external app. An AI app builder removes that excuse. It generates the external app — UI, OData integration and logic — in days, validated against your data model, so the clean approach is also the fast one.