AI chatbotInfor VISUAL Agent view

How to add an AI chatbot to Infor VISUAL

Short answer

An AI chatbot for Infor VISUAL answers questions from live ERP data through a fixed set of read-only lookups plus retrieval over your documents. It can sit in a web page, Teams or a portal, and it can run entirely on-prem with an open-weight model when data must stay in the plant.

VISUAL users spend a lot of time opening windows to answer questions that are simple to ask and tedious to answer: when will this ship, do we have the material, what did we pay last time. A chatbot front end removes the navigation without replacing the system.

There are two audiences. Internal users want fast lookups and explanations. Customers and vendors want a status answer without phoning someone. The second audience needs much stricter scoping, because the bot can only ever show them their own records.

A good bot is boring in the right way: it cites the order, shows the date, and says when it cannot find something. It is not a creative writer with database access.

What teams use it for

Internal order and job lookup

Planners and CSRs ask about customer orders, work orders and shipments in plain language and get a short answer with the record ids.

Customer order status portal

A logged-in customer asks where their order is. The bot only reads records tied to that customer id and shows promised and ship dates.

Vendor self-service

A vendor asks which POs are open and what dates are expected, and can confirm a date through a form that a buyer reviews.

Procedure and quality Q&A

Retrieval over work instructions and quality procedures lets operators ask how to handle a nonconformance, with the source cited.

New hire onboarding

A bot explains how a part flows through routing, which windows to use, and where reports live, using your own documentation.

Infor VISUAL integration surface

  • Read-only views over the VISUAL SQL Server database for the structured answers, such as CUSTOMER_ORDER, CUST_ORDER_LINE, WORK_ORDER, PURC_ORDER_LINE and shipment tables. Confirm names in your version.
  • Customer and vendor identifiers that let you scope every query by external user, so a portal user can see only their records.
  • Document stores such as file shares or SharePoint for retrieval over procedures, certificates and drawings.
  • Hosting surfaces for the front end: an internal web page, Microsoft Teams, or a customer portal with its own login.
  • Optional Infor ION or toolkit interfaces for creating records, normally kept out of a chatbot beyond a request form.

How it works

  1. 1

    Separate internal and external bots

    Do not share one configuration. External access needs identity, row scoping and rate limits that internal users do not.

  2. 2

    Define the question catalog

    Write down the twenty to forty questions that cover most traffic, and map each to a query or a document search.

  3. 3

    Build lookup tools and retrieval

    Create parameterized, read-only queries. Index documents in a vector store with source metadata so answers can cite them.

  4. 4

    Ground the answers

    Instruct the model to answer only from tool results and retrieved text, show record ids, and say it does not know when nothing is returned.

  5. 5

    Add identity and scoping

    Tie each session to a user. For customers, force a customer id filter in code, never in the prompt.

  6. 6

    Choose where the model runs

    A hosted API for lower-sensitivity use, or an open-weight model served locally for plants that cannot send data out.

  7. 7

    Test with real transcripts

    Replay a month of actual questions, score accuracy, and fix gaps before opening to customers.

Example flows

Customer asks about shipment timing

Trigger: Customer types 'when will PO 8841 ship?' into the portal bot

  1. Session identifies the customer account.
  2. Tool looks up order lines matching that customer PO number.
  3. It returns line status, promised date and shipped quantity.
  4. Bot replies with the dates and offers to notify a CSR if the date has slipped.

Result: The customer gets a self-service answer and the CSR only sees exceptions.

Operator asks about a procedure

Trigger: Operator asks how to tag nonconforming parts on a job

  1. Bot retrieves the relevant section of the quality procedure.
  2. It summarizes the steps and quotes the source name and revision.
  3. It offers a link to open the document.

Result: Operators get consistent guidance tied to the controlled document.

Keeping data on-prem

A VISUAL chatbot can run fully inside the plant. Host the front end on an internal web server, run the lookup service next to SQL Server, index documents on a local vector store, and serve an open-weight model such as a Qwen, Llama or Mistral class model on a local GPU. For customer access, put only an authenticated front end in a DMZ and keep the model and database behind it. Smaller models handle structured lookups well, but expect weaker performance on long, messy documents than larger hosted models.

Security checklist

  • Enforce customer or vendor scoping in code on every query.
  • Treat user text as untrusted and never let it alter tool parameters beyond typed fields.
  • Rate limit and log external sessions, and avoid storing personal data you do not need.
  • Keep the bot read-only; send changes to a form or a person.
  • Version and review the document index so superseded procedures do not get cited.

Ways to get it done

Build on an open-source chat framework

Effort: Weeks for a solid internal bot, longer for external users.

In-house developers and an internal-only audience.

Use a hosted chatbot platform with a custom data connector

Effort: Days to weeks, plus the connector to SQL Server.

You accept cloud processing and want quick deployment.

Partner build such as Netray

Effort: Scoped pilot on internal users first, then external.

You need on-prem hosting, customer scoping and ongoing tuning.

Pitfalls

  • !Putting customer scoping in the prompt instead of the query.
  • !Letting the bot answer from memory when a lookup fails.
  • !Indexing every file share, including obsolete procedures, which creates confident wrong answers.
  • !Launching to customers before testing on real, messy questions.
  • !Ignoring who owns the bot after launch, so answers go stale.

Frequently asked questions

Can the chatbot show live VISUAL data?

Yes, by calling read-only lookups against the SQL Server database at question time. It does not need to copy the data elsewhere, although a reporting copy can reduce load on production.

Is it safe to expose a bot to customers?

It can be, if every query is filtered by the authenticated customer in code, the bot is read-only, and you test for prompt injection. Start with internal users and add customers afterward.

Which model should power it?

For structured lookups, a current open-weight model served locally is often adequate. For nuanced document questions or multilingual use, a larger hosted model may do better if your policy allows it.

Does it need a new VISUAL version?

Generally no. Because it reads the database, it works on older installs too. Anything that creates records depends on what your version's toolkit supports.

How is this different from Power BI Q&A?

Power BI works from a modeled dataset and charts. A chatbot can combine live lookups, documents and follow-up questions in conversation. Many plants use both for different jobs.

Want AI chatbot working on your Infor VISUAL?

A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.

Get a free assessment