How it works
From a sentence to a committed IFS transaction
Nothing here is hidden behind a black box. You can watch which projection it searched, which endpoint it called, what came back, and exactly what it is about to write — while it happens.
Raise a requisition for 20 bearings, part 74821, needed Friday
Two things IFS needs that you have not given me: the site and the buyer.
- Site options came from your IFS LOV: 100, 200, 300
- Buyer defaults to a.kaur from your IFS user record
Site 100, buyer is fine
Confirm before writing to IFS
- Part
- 74821
- Qty
- 20
- Site
- 100
- Wanted
- 2026-08-07
- Buyer
- a.kaur
Requisition 90441 created
- Requisition
- 90441
- State
- Planned
How does NgageChat turn a question into an IFS Cloud transaction?
NgageChat works in five stages: it routes the request to the relevant IFS domain, finds the right IFS projection and entity set, resolves required fields, enums and IFS defaults — reading your custom fields live from your environment — shows you the complete payload for approval, then executes against your IFS OData REST API.
Last reviewed 3 August 2026 · NgageChat by EX10
01
Route to the right domain
An intent router matches your wording against ten IFS domains — work orders, supply chain, finance and the rest — and loads the domain knowledge for that area. Asking about a shop order and asking about an expense sheet are different jobs.
Deterministic keyword routing, not an extra model call. Earlier topics in the conversation get a small stickiness bonus so a follow-up question does not lose context.
02
Discover the API
NgageChat searches its index of the IFS Cloud data model for the projection and entity set that own the data, then pulls the full API spec: keys, fields, enums, bound actions and function imports. Your custom fields are read live from your environment and layered on top.
This is what separates an assistant that works on your IFS from one that works on a generic idea of IFS.
03
Resolve every value
Before a write, it reads the required fields, calls the entity’s _Default() function for IFS’s own defaults, and resolves each constrained field: enum values first, then list-of-values, then a plain text box. Anything still missing comes back to you as a short question.
An empty dropdown is never filled in with plausible-looking options. If NgageChat cannot find real values in your system, it says so.
04
Show you, then wait
The complete payload is rendered as a readable summary — every field, including values that came from defaults. Nothing reaches IFS until you approve it, and you can change a value there rather than restating the whole request.
Read requests skip this step. Only writes and actions require confirmation.
05
Execute and record
The call goes to the IFS OData REST API with the signed-in user’s access token. Updates carry the current ETag so a parallel change cannot be silently overwritten. The record identifier comes back so you can verify it in IFS.
Every message and tool call — parameters, result, model, duration, errors — is written to the conversation log.
The IFS details that matter
Six behaviours that decide whether a write succeeds
Most ERP integration failures are not clever. They are a wrong URL shape, a missing ETag, or an action called the wrong way. NgageChat handles these because it was built for IFS specifically.
_Default() resolution
New records start from IFS’s own defaults by calling the entity set’s bound _Default() function — a GET, not a POST, with the entity set before the namespace-qualified function name. Getting this wrong is the classic reason ERP integrations cannot create records.
ETag concurrency
Updates send the current ETag with an If-Match header. If someone changed the record first, IFS rejects the write and you are told — instead of one person’s edit quietly erasing another’s.
Bound actions vs action imports
Release, approve and complete are bound actions on a specific record. Wizard-style commits such as CreateExpenseHeader and FinishInvoice are unbound action imports on the projection. NgageChat uses the right one, because using the wrong one returns nothing useful.
Enum → LOV → text fallback
Field options are resolved in a fixed order: enumeration values first, then list-of-values, then a plain text box. Fields such as IsoLanguage and IsoCountry look like enums but are driven by LOVs — so the fallback chain matters, and an empty dropdown is never filled in with invented options.
Query construction
$select, $filter, $expand, $orderby, $top and paging are built from your question and validated against the entity’s real fields, so filters reference columns that exist.
Site-aware server time
Dates are stamped using IFS server time adjusted for the relevant site’s timezone, because a plant in Gothenburg and a plant in Houston do not share "today".
Domain knowledge
Ten IFS areas, loaded on demand
Only the domain knowledge relevant to your request is loaded, which keeps answers fast and focused.
FAQ
How it works — questions
How does NgageChat connect to IFS Cloud?
Does it need a copy of our data?
What happens between me asking and the answer appearing?
Why does it ask me questions back?
Can I see what it did?
For how the five AI products in the suite fit together, see AI for IFS on Ngage Suite.
Early access
See NgageChat answer a question from your own IFS environment
A 30-minute session: bring one real scenario — an overdue work order list, a fault report, a supplier lookup — and watch it run end to end. No slideware.