How to add an AI chatbot to Infor XA
Short answer
An AI chatbot for Infor XA answers questions from live Db2 for i data through a controlled tool layer, not from the model's memory. You can place it in an intranet page, a customer portal or a messaging channel, enforce role-based access, and run the model on your own hardware so data stays on-prem.
XA green-screen and web users spend a lot of time asking the system the same questions: where is this order, what is the stock, when does this PO arrive, what did we quote this customer last time. A chatbot is a different front end to the same answers. It matters most for occasional users, such as sales, customer service and supervisors, who never learned the inquiry programs well.
The cheap version, a chatbot that answers from a pasted FAQ, is not useful for ERP. The useful version is grounded: when someone asks about order 48213, the bot looks up order 48213 and answers from the result, citing it. If the lookup returns nothing, it says so. That discipline is the difference between an assistant people trust and one they stop using after a week.
For XA the real engineering sits behind the chat window: views over Db2 for i, role mapping, and the choice of where the model runs. Interface choice, web widget or messaging, is the easy part.
What teams use it for
Customer service order status
Reps ask where an order stands, and the bot answers with ship date, carrier reference and any hold reason, without opening three XA programs.
Customer self-service portal
Your customers ask about their own orders, invoices and shipments through a portal chat, restricted to their account by the tool layer.
Supervisor shop floor questions
A supervisor asks which jobs are behind at a work center and what component is short, from a tablet at the line.
Procedure and policy answers
Using retrieval over your own SOPs and work instructions, the bot answers how-to questions and links the document, kept separate from live data answers.
New user onboarding for XA
New buyers and planners ask what a screen or code means, using your own glossary of statuses and order types.
Infor XA (on IBM i) integration surface
- Read-only Db2 for i views, accessed with a JDBC (jt400) or ODBC connection from a service outside the IBM i, supply the live answers. Release-specific file names must be mapped by someone who knows your install.
- XA user and role information (security setup in the application and IBM i user profiles) determines what each person may see. The chatbot must carry the user's identity into the tool layer; the model never decides access.
- IBM i Integrated Web Services or stored procedures can wrap RPG business logic such as price lookup and availability so the bot reuses it.
- Documents for retrieval come from file shares, the IFS or a document system, separate from the transactional data, and should be indexed with access labels.
- Single sign-on options depend on your environment; many XA sites authenticate against Active Directory or Entra ID for the web layer and map to IBM i profiles behind it.
How it works
- 1
Choose the audience first
Internal staff and customers have different risk profiles. Begin internal, with a user group of ten to thirty people, before opening anything to customers.
- 2
Define the question set
Collect the fifty most common questions from help desk tickets and email. Group them into lookups (live data) and knowledge questions (documents).
- 3
Build tools and retrieval
Implement a tool for each lookup group over SQL views and a retrieval index for documents. Keep the two paths separate so a document cannot override a live number.
- 4
Wire identity and permissions
Authenticate the user at the chat layer, map to an XA role, and pass that identity to every tool call. Customer chats are bound to a customer account number server-side.
- 5
Select the model and prompt rules
Use an open-weight model on your GPUs or a hosted model if policy allows. Instruct it to answer only from tool results, to quote identifiers, and to hand off to a person when unsure.
- 6
Deploy the interface and add a handoff
Add the chat to an intranet page, a customer portal, or a channel such as Teams. Include a clear way to escalate to a human with the conversation attached.
Example flows
Rep checks order status
Trigger: Customer calls asking about order 48213
- Rep types the order number in the chat window.
- The bot calls get_order_status, which reads the order header, lines and shipment records.
- It replies with line status, planned ship date and, if the order is on hold, the hold reason code translated using your glossary.
Result: The rep answers on the call without switching screens, and the figures come from the system.
Customer portal invoice question
Trigger: Customer asks: which of my invoices are still open?
- Portal passes the logged-in customer's account number to the backend, not to the model.
- The tool returns open invoices for that account only.
- The bot lists them with due dates and links to the PDF copies kept in your document store.
Result: Fewer routine AR calls, and no way for one customer to see another's data.
Keeping data on-prem
A chatbot over XA runs comfortably fully on-prem. Host the chat service, the retrieval index and an open-weight model on a GPU server in your data center, with the IBM i reachable only from the service. The model sees only the rows returned by tools for that user. For customer-facing chat, put a reverse proxy in a DMZ that forwards only authenticated sessions, and keep model and data tiers behind it on the internal side. Smaller models are enough for status lookups; a larger model helps when you add document reasoning. Plan capacity by concurrent users, not total users.
Security checklist
- Bind every session to a verified identity, and enforce data scope in the tool layer, never in the prompt.
- For customers, scope by account number server-side and test with attempts to ask about another account.
- Keep cost, margin and supplier pricing out of the tools exposed to external or low-trust roles.
- Log questions, tool calls and answers with retention aligned to your policy, and redact personal data where required.
- Rate-limit and filter inputs to blunt prompt injection and abuse, particularly on customer-facing chat.
Ways to get it done
Use a general chatbot platform with an API connector
Effort: Quick to launch, but live data access to IBM i usually needs custom middleware anyway.
Documentation-style bots where live ERP data is limited.
Build in-house on views, a tool layer and an open model
Effort: A pilot in several weeks; role mapping and evaluation take the longest.
You have developers and want full control and on-prem hosting.
Deploy a partner-built chatbot such as Netray's ERPray approach
Effort: Scoped by audience and question set, starting with a small internal group.
You want grounded answers, a visible query and role respect with an on-prem option.
Pitfalls
- !Launching to customers first. Learn on internal users, where mistakes are cheap.
- !Letting the model decide permissions. Access control belongs in code that the model cannot talk its way past.
- !No evaluation set. Keep a list of real questions with known answers and rerun it after each prompt or model change.
- !Answering from stale cached data without saying how old it is. Show the as-of time.
- !Skipping the human handoff, which turns every wrong answer into a lost customer.
Frequently asked questions
Will the chatbot make things up?
It can if you let it answer without data. Constrain it to tool results, require it to cite order or item numbers, and have it say it cannot find something when the lookup returns nothing. Test with a fixed question set to catch regressions.
Can customers use it safely?
Yes, if scope is enforced server-side by account number and the exposed tools are limited to what a customer is allowed to see. Start internal, red-team the customer version, and keep a human escalation route available.
Does it need to write to XA?
No. Most value comes from read-only answers. If you later add actions such as creating a return request, route them through a staging step and approval so XA's own validation still applies.
Can it run without internet access?
Yes. With an open-weight model on your own GPUs and local retrieval, the whole stack can run disconnected. You give up hosted frontier models, but status and lookup questions rarely need them.
Is Infor's own assistant enough?
If you are on a cloud product with a built-in assistant that covers your questions, use it. Many on-prem XA installations have no equivalent, or need answers that blend XA data with your documents, which is where a custom chatbot helps.
Want AI chatbot working on your Infor XA (on IBM i)?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment