Infor
Infor builds industry-specific ERP — different products for manufacturing, healthcare, hospitality and distribution rather than one system configured many ways. Its depth is the point, and its depth is also why so few people have access to it.
Infor builds industry-specific ERP — different products for manufacturing, healthcare, hospitality and distribution rather than one system configured many ways. Its depth is the point, and its depth is also why so few people have access to it.
What Infor holds, and why that matters here
Infor deployments are typically vertical: CloudSuite for a particular industry, with terminology and process built in rather than configured. That means the system already speaks the language of the business, and the operational record it holds is unusually specific — production, clinical supply, property, distribution.
The consequence for contact is that the questions people ask are highly domain-specific and highly repetitive, which is the ideal profile for an assistant. The answers are precise, they exist, and they are locked behind a system with narrow licensing.
- Operations — production, work orders and scheduling for the relevant vertical.
- Inventory and supply — stock, movements and replenishment.
- Finance — invoices, payments and supplier state.
- Assets — equipment, maintenance and service history where the module is used.
- Vertical records — the domain-specific objects the particular CloudSuite is built around.
Questions Elbi can answer from Infor
What is the status of this work order?
Where a job sits and what it is waiting on.
Do we have the parts?
Component and consumable availability for the people who need it now.
When is maintenance due?
Service schedule for a piece of equipment.
Has the supplier delivered?
Receipt state against a purchase order.
What is the current position on this line?
Vertical-specific operational status, phrased in the language the business actually uses.
Who is assigned to this?
Ownership and assignment for internal follow-up.
How Elbi reads Infor
- Through the ION API GatewayInfor OS publishes the ERP's APIs through the ION API Gateway, the supported front door for CloudSuite deployments. The assistant reads through the gateway rather than the database, so access is governed by Infor's own security rather than a database login. On older on-premise releases, the route is agreed with your Infor team.
- An authorised app and a service accountYour Infor administrator registers the assistant as an authorised app in ION API and ties it to a service account whose roles in the ERP are restricted to what is in scope. The credentials are generated in your tenant, and the app can be disabled there whenever you choose.
- OAuth rather than passwordsThe gateway uses OAuth, so the assistant holds a token for that app and account rather than anyone's password. Nobody's personal login is involved, and staff changes do not break the connection.
- Questions reach the right domain objectA work order in a plant, a requisition in a hospital store and a maintenance job on a property are different objects in different CloudSuites. The mapping done at deployment means "has the pump been serviced" reaches the right record and comes back in the words your staff use.
- People are identified before anything is readStaff are identified through your own sign-in, usually on a phone, and answered within what their role would show them. Suppliers are matched to their own supplier record and see nothing beyond it.
- Write-back is rare and deliberateReads are the default. Raising a maintenance request or logging a note against a work order can be enabled per action, with a person confirming if you want one.
Infor roles, service accounts and what stays yours
| Direction of access | Read-only by default. Anything that creates or changes a transaction is enabled per action and can be held for human confirmation. |
|---|---|
| Who can see what | The service account's ERP roles fix what the assistant can reach, by site, warehouse or company as your product allows. Within that, each person sees only what their own role would show — a store supervisor their store, a supplier their own orders. |
| Credentials | The authorised app and service account live in your Infor OS tenant. Revoking them there stops the connection at once and needs nothing from us. |
| Where data goes | Work order, stock and supplier details read from Infor answer the question and go no further. Conversation content is destroyed within 24 hours — usually once the conversation ends — and no external AI service ever sees it. |
| Audit | Every lookup can be logged with the question, the record read, the agent and the conversation, so a dispute about what the floor was told can be settled from the log. |
| If it is unavailable | During a maintenance window or an outage, the assistant tells the person it cannot reach Infor and offers a colleague — which matters more when the asker is on a production line than at a desk. |
What this replaces in an Infor operation
Because Infor is vertical, its terminology is domain-specific, and that is precisely where generic assistants fail. A system that answers in generic ERP language to people who speak in industry terms creates friction on every exchange. Matching the assistant to how the business actually talks is part of deployment rather than an afterthought.
The internal case is usually stronger than the customer-facing one. Infor tends to be used by operational staff who are not at desks — on a production line, in a hospital store, across a property estate — and for whom opening a client is impractical. A conversational interface on a phone is the right shape for that population.
Where there is a customer-facing case, it is usually supply chain: partners and suppliers asking about orders, receipts and payments, which is high-volume and low-judgement.
How Infor's verticals use it
Manufacturing
Work order and component questions from the floor rather than the office.
Healthcare
Clinical supply and equipment questions where delay has real consequence.
Hospitality
Property and operations questions across sites.
Distribution
Stock, movement and delivery questions at volume.
Getting value from Infor
Start with the product you run and the people furthest from a screen. In manufacturing that is usually work order and component questions from the floor; in healthcare, supply and equipment questions from wards and stores; in distribution, stock and delivery questions from the warehouse and from customers. The first scope follows from that, not from the breadth of the CloudSuite.
Vocabulary decides adoption. A vertical ERP is chosen because it speaks the business's language, and an assistant that answers with a status code instead of "released to the floor" will not be asked twice. Agreeing the terms with the people who will use it is worth more than any extra field.
Keep analysis in Birst or whatever reporting layer you already use. The assistant is for the state of one order, one item or one asset, right now.
What connecting Infor involves
- Name the product and the questionsM3 or LN, CloudSuite Industrial, a healthcare or hospitality product — each exposes different objects. The questions and the product together decide which APIs are needed.
- Work with your Infor administrators and partnerInfor deployments are usually run with an implementation partner or Infor's own services team, who know the ION set-up and extensions in your tenant and own the security changes.
- Register the app and restrict the service accountAn authorised app in ION API, a service account with read-only roles, and restrictions by site or company. The credentials never leave your control.
- Map the domain objects and termsWork order types, location codes, asset classes and user-defined fields are mapped to the words your staff actually use, in Arabic and English.
- Test on a phone, not just a deskA work order split across operations, an item held at several sites, an asset with no service history, someone asking about another supplier's delivery. The unhappy paths are tried in a non-production tenant where you have one, on the devices people will use.
- Launch with one site or teamOne plant, one hospital store or one warehouse first, widened after a month of real questions.
Personal and operational data in Infor
Infor's vertical products hold personal data that is easy to overlook: technician and operator names on work orders, employee details where HR modules are used, guest details in hospitality products. Under the Saudi Personal Data Protection Law, none of that should be reachable by an assistant built to answer stock or work-order questions, and the service account's roles are where you make sure of it.
For supplier-facing use, identify the supplier before any order or payment detail is disclosed, and keep bank details out of scope. For staff on the floor, keep the log that shows what was read and for whom, and make sure people know, in the language they work in, that their questions are answered from Infor.
What Infor organisations typically see
Other ways Infor organisations handle this
Infor has its own AI and assistant offerings on Infor OS, including the Coleman platform, and Ming.le gives licensed users a single workspace across Infor applications. For people who already work in those tools, they are the obvious place to ask.
For everyone else the usual alternatives are a shared terminal on the floor, a printed report, or a phone call to whoever has access. They all work, slowly, and none of them is available to a supplier or a night shift.
Where Infor connections go wrong is generic language. An assistant that translates everything into textbook ERP terms throws away the reason the business chose a vertical product. The other failure is a broad service account granted "for now", which a security review will rightly stop.
Plan for the unhappy path too: a maintenance window, a job number misheard on a noisy floor, an item that exists at several sites. "I could not find that in Infor", and a route to a person, keeps the floor trusting it.
Common questions about Infor
That is configured during deployment. A vertical ERP is chosen because it speaks the business language; the assistant is matched to the same language rather than translating into generic terms.
That is usually the strongest argument for this. A conversational interface works on a phone, in either language, without training.
The approach is the same across CloudSuites; what differs is which interfaces your particular product exposes, established during deployment.
No. The assistant uses an authorised app and service account created in your Infor OS, with the roles you assigned. You can revoke either at any time without going through us.
Through ION API wherever it is available, because that is Infor's supported route and keeps Infor's own security in the path. Older on-premise releases without it are assessed case by case.
If you enable it. A maintenance or work request is a sensible first write-back for floor staff, and it can be held for a supervisor to confirm before it reaches Infor.
Connect it to your own systems
A working assistant against your own records, in both languages.