How natural-language queries reach IFS Cloud data
For technical evaluators: what happens between someone typing a sentence and a row coming back from IFS, and where the design decisions actually are.
In short
A natural-language query against IFS Cloud is translated into an OData REST request in four steps: find the projection that owns the data, read that entity’s real field definitions, build a $filter/$select/$expand query validated against those fields, then execute it with the signed-in user’s IFS access token so permissions are enforced by IFS.
- IFS Cloud exposes data through projections; finding the right one is the first and most important step.
- Queries are validated against real field metadata, so filters cannot reference columns that do not exist.
- Execution uses the end user’s own IFS token, which is what makes permission enforcement free and correct.
- No replica, no warehouse, no sync — the query runs against IFS at the moment it is asked.
How does a sentence become an IFS query?
The sentence is not translated directly into a query. It first drives a discovery step: search IFS metadata for the projection and entity set that own the data, retrieve that entity’s field definitions, and only then build the OData request. Skipping discovery is why generic assistants produce queries that reference fields IFS does not have.
- Route — the request is matched to an IFS domain (work orders, supply chain, finance and so on) so the right domain knowledge is in play.
- Discover — search your IFS pages and projections for the entity set that handles this data.
- Inspect — read the entity API spec: keys, fields, types, enums, bound actions, function imports.
- Compose — build $select, $filter, $expand, $orderby and paging against those real fields.
- Execute — call the IFS OData REST endpoint with the signed-in user’s access token.
- Render — return the result as prose, a table, or a chart if that is what was asked for.
What is a projection in IFS Cloud?
A projection in IFS Cloud is a published API surface over part of the data model. It exposes entity sets, their fields, bound actions and function imports, and it is also the unit at which IFS grants access: a permission set assigns each projection a level of none, read-only, custom or full.
That last point is the one that matters most for AI. Because access control lives at the projection level and is enforced by IFS, an assistant calling IFS as the real user inherits the correct answer to "who is allowed to see this" without implementing any access logic of its own.
It also means an assistant is exactly as capable as the account it uses. Point it at a service account with full grants everywhere and you have built a permission bypass with a chat interface on the front.
Does it query live data or a copy?
A well-designed IFS assistant queries live. The request goes to your IFS Cloud OData endpoints at the moment you ask, so the number returned is the number IFS holds right then. There is no replica to keep in sync, no extract window, and no class of bug where the answer was true four hours ago.
The trade-off is honest: live querying means the assistant needs connectivity to IFS, and very large aggregations are bounded by what the OData layer will return efficiently. For genuinely heavy analytics across years of history, a reporting platform remains the right tool.
For the operational questions people actually ask all day — what is late, what is short, where is it, who owns it — live is both fast enough and considerably more useful than a copy.
How are writes different from reads?
Writes need more discovery than reads. Before creating a record, an IFS assistant reads the required fields, resolves enumeration and list-of-values options, calls the entity’s _Default() function for IFS’s own defaults, and assembles a payload that matches the endpoint’s documented field definitions. Only then does it show the user a summary to approve.
Updates add concurrency handling: the current ETag is sent with the PATCH so IFS can reject the write if the record changed in the meantime. Actions split into two kinds — bound actions on a specific record, such as releasing a work order, and unbound action imports on the projection, used by wizard-style flows such as expense sheets.
Using the wrong kind is a common integration failure. A function import called through a data query returns zero records rather than an error, which is exactly the sort of silent wrongness that erodes trust in an assistant.