Skip to content

IFS Cloud integration

27 native IFS tools, and no core modifications

NgageChat speaks IFS OData fluently — projections, entity sets, _Default() resolution, ETag concurrency, bound actions, action imports. Not a generic connector pointed at an API.

How does NgageChat integrate with IFS Cloud?

NgageChat integrates with IFS Cloud through published OData REST APIs using 27 native tools. Six discover metadata, three read field-level endpoint schemas, eleven execute reads, writes and IFS actions, four handle specialised field operations, and three cover documentation search and conversation recall. No database access, no core modification.

Last reviewed 3 August 2026 · NgageChat by EX10

Metadata discovery

Find the right place in IFS before touching anything. All read-only.

6 tools

NgageChat ships a curated index of the IFS Cloud data model rather than guessing at it: projections, entity sets, keys, required fields, enums and list-of-values. Your custom fields are layered on top, read live from your environment’s IFS Solution Manager metadata APIs and cached per server.

search_ifs_pages

Find IFS pages and projections by keyword — the first step in almost every request.

get_ifs_entity_api_spec

Retrieve the complete API spec for a page or projection: entity sets, keys, actions, functions.

get_ifs_page_details

Full page metadata — form groups, visibility rules and every entity set the page touches.

get_ifs_required_fields

The fields IFS actually requires to create a record, so nothing is guessed.

get_ifs_enum_values

Valid enumeration values for a field, straight from your data model.

get_ifs_lov_details

List-of-values configuration for lookup fields — the real dropdown, not an invented one.

API schema

Know the exact payload before writing, so the first attempt is the one that succeeds.

3 tools

Before any create or update, NgageChat reads the field-level endpoint definition: every payload field split into required and optional, each with its type, maximum length and permitted values. Wrong-shape writes are the main reason ERP integrations fail; this is how they are avoided.

fetch_api_endpoints

List available endpoints for a projection, filtered by method or name.

fetch_api_details

Full field-level detail for a specific endpoint — required vs optional, types, lengths, enums.

get_ifs_crud_endpoints

The create, read, update and delete surface exposed for an entity.

Execution

The part most ERP chatbots skip: actually doing the thing.

11 tools

Reads, writes, bound actions and function imports over the IFS OData REST API — with IFS defaults resolved first, ETag concurrency respected, and a confirmation step before anything is committed.

ifs_read_data

Query IFS with filters, expands, ordering and paging built from your question.

ifs_create_record

Create a record, after defaults, required fields and enums have been resolved.

ifs_update_record

Update a record using ETag concurrency so a parallel change is never silently overwritten.

ifs_delete_record

Delete a record, subject to IFS permissions and an explicit confirmation.

ifs_get_defaults

Call the entity’s _Default() bound function so new records start from IFS’s own defaults.

ifs_execute_action

Run a bound action on a specific record — release, approve, complete, cancel.

ifs_call_action_import

Call an unbound action import for wizard-style flows such as expense sheets and invoices.

ifs_call_function_import

Call read-only OData function imports like GetInitValues() and GetCurrentUser().

ifs_search_lov

Search a list-of-values endpoint to resolve a name you typed into the code IFS expects.

ifs_batch_changeset

Group related writes into a single OData changeset when they must succeed or fail together.

ifs_get_server_time

Get IFS server time adjusted for a site’s timezone, so dates land on the right day.

Specialised operations

Common field tasks wired straight through, with no discovery round trip.

4 tools

Some things happen often enough to deserve a direct path. These call the right IFS service immediately, which is why reporting an incident from a phone takes seconds.

ifs_report_hse_incident

Report an injury, near miss, spill or property damage to the IFS HSE service.

ifs_record_meter_reading

Record a meter or condition-monitoring reading against equipment.

ifs_list_meter_readings

Retrieve reading history for a piece of equipment.

ifs_attach_document

Create a document reference against a work order, asset or fault report.

Knowledge & recall

Answer how IFS works, and remember what you already discussed.

3 tools

A semantic search over official IFS Cloud documentation covers the "how does this work" half of the job, and conversation recall means a long session does not lose the work order number you mentioned forty messages ago.

search_ifs_docs

Semantic search over official IFS Cloud documentation, returning context plus diagrams and screenshots.

search_ifs_by_component

Narrow discovery to a specific IFS component when you already know where you are.

recall_old_context

Look up details from earlier in a long conversation after it has been summarised.

OData, done properly

The IFS conventions that make writes work

These are not exotic edge cases. They are the specific reasons a well-intentioned integration returns a 400 instead of a record.

_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".

What is not installed

Nothing goes into your IFS environment

  • No database connection and no direct SQL.
  • No custom entities, projections or core code deployed into IFS.
  • No credential minted by us — IFS issues and refreshes every token.
  • No replica, warehouse or scheduled extract of your IFS business data — every record is read live.
  • No IFS screen scraping or browser automation.

If you want the layer below this — how a plain-English sentence becomes a valid OData query against your entities — that is covered in how natural-language queries reach IFS Cloud data.

The consequence is a clean upgrade path. The data-model index is maintained by us and tracks IFS releases; your custom fields are re-read live from your environment; and everything runs through published REST endpoints — so there is nothing in your core to re-apply after an IFS release.

FAQ

Integration questions

How does NgageChat integrate with IFS Cloud?
Through IFS’s published OData REST APIs. 27 native tools handle metadata discovery, field-level endpoint schemas, live create/read/update/delete, bound actions and action imports, specialised field operations, and semantic search over official IFS documentation. There is no database access and no core modification.
Does it need custom IFS development to install?
No. NgageChat consumes standard IFS projections. Nothing is deployed into your IFS environment, no entities are added, and no core code is changed — which is what keeps your upgrade path clean.
Will it work with our custom fields?
Yes. Custom fields are the one part of the data model that cannot come from a shared index, so NgageChat reads them live from your environment’s IFS Solution Manager metadata APIs — EntityConfigHandling and ProjectionConfigHandling — and caches them per server. They then behave like any other field.
What about IFS releases — will an upgrade break it?
Nothing is installed in your core, so there is nothing to re-apply after an upgrade. The data-model index is maintained by us and tracks IFS releases; your custom fields are re-read live, so changes there are picked up without any work at your end. Tell us your IFS version and we will confirm exactly what is supported.
How does it authenticate to IFS?
In the browser, each user signs in with their own IFS account over OpenID Connect using authorisation-code flow with PKCE, and token exchange and refresh go through stateless server-side proxies. Embedded sessions and password-only logins currently use a configured connection instead — see the security page for what that means for your deployment.
Can it handle bulk or transactional operations?
Related writes that must succeed or fail together can be grouped into a single OData changeset. For high-volume, unattended, scheduled processing, an agentic workflow product is the better tool — that is NgageFlow’s job in the suite.

Early access

Bring your environment, we will show you the trace

A working session against your own IFS Cloud tenant: watch it discover a projection you know, build the query, and return your data.