AdvancedInfor SyteLine (CloudSuite Industrial) on-premAI integration / Mongoose IDOs and SQL Server

Private AI Layer for SyteLine On-Prem: Reference Architecture

Question
how to add AI to SyteLine on-prem

Also searched as

  • SyteLine AI integration without cloud
  • private LLM for Infor SyteLine on SQL Server
  • SyteLine IDO REST API for AI assistant
  • CloudSuite Industrial on-prem chatbot

Short answer

To add AI to SyteLine without moving data to a cloud, keep SQL Server and the Mongoose application tier where they are, expose a read-only reporting copy and approved IDO calls to a tool server, and serve an open-weight model with vLLM or Ollama on local GPUs. Mirror SyteLine user groups and site access in the tool server, log every prompt and query, and send any write-back through IDO methods with human approval.

Applies to: Infor SyteLine 8.x and CloudSuite Industrial 9.x/10.x on-premises, SQL Server back end, Mongoose application framework

How to build a private AI layer on SyteLine

  1. 1Inventory the data the assistant needs: items, customer orders, jobs, POs, inventory, plus attached documents such as drawings, certs and work instructions.
  2. 2Stand up a read-only path: an AlwaysOn secondary or a log-shipped reporting copy of the SyteLine databases, plus a service account with SELECT only.
  3. 3Decide per question type whether to read through IDOs (permission-aware, business logic applied) or through SQL views on the reporting copy (faster for aggregates).
  4. 4Build a retrieval index over documents and attachments with a local embedding model and a vector store inside the same network zone.
  5. 5Expose approved read actions through an MCP or tool server; every tool maps to one named IDO load or one parameterised query, never free SQL.
  6. 6Serve an open-weight model (Qwen, Llama, Mistral or gpt-oss class) with vLLM or Ollama on local GPUs, behind the tool server and an audit log.
  7. 7Roll out in three phases: read-only questions, then drafts (PO notes, NCR text, quote emails), then approved actions through IDO methods.

Data access paths in SyteLine

SyteLine stores data in SQL Server. Multi-site installations use tables with an _mst suffix (for example item_mst, coitem_mst, co_mst, job_mst, po_mst) carrying a site_ref column, and views without the suffix that filter to the current site context. Querying the base tables directly bypasses that site filtering, so a reporting copy needs its own site rules.

The supported programmatic layer is the Mongoose IDO (Intelligent Data Object). IDOs wrap tables with business logic, calculated properties and user permissions. They are reachable through the IDO request service over REST and SOAP, and through the ION API gateway when Infor OS is installed. For an AI layer, IDOs are the safest read path for single-record and short-list questions; SQL on a reporting copy is better for aggregates and trend questions.

Attachments live in Mongoose document objects linked to records, and many plants also keep drawings and certs on file shares. Index both.

-- Reporting copy, read-only service account, one site
SELECT TOP 50 i.item, i.description, i.u_m, i.unit_cost
FROM dbo.item AS i
WHERE i.stat = 'A'
ORDER BY i.item;
GET /IDORequestService/ido/load/SLItems?properties=Item,Description,UnitCost&filter=Item%20LIKE%20'BRK%25'&rowcap=50
Authorization: <token from the configuration's token endpoint>
-- Verify the IDO name and property names in your IDO metadata before use.

Reference architecture

Put five components inside the plant network: a reporting replica of the SyteLine databases, a document index, a tool server, a model server and an audit store. The tool server is the only component that talks to SyteLine; the model never receives credentials and never builds SQL against production.

Change data capture or scheduled extracts keep the document index and any denormalised search tables fresh. For an air-gapped site, load model weights, container images and Python wheels through a controlled transfer station and pin versions; nothing in the runtime path needs internet access.

Typical models for this workload are 8B to 32B open-weight models for question answering, plus a small embedding model. Larger models help on multi-step analysis but are not required for lookups.

Permissions, sites and write-back

SyteLine authorisation is built on Mongoose user groups, form and IDO method permissions, and site access. The assistant must act as the asking user: authenticate the user through your identity provider, map them to their SyteLine user, and call IDOs with that identity, or filter reporting-copy queries by the same site and group rules. A shared service account that sees everything is the failure to avoid.

Write-back should go only through supported IDO methods or Infor-documented APIs, never UPDATE statements. Keep the assistant to drafts first: a proposed PO change, a drafted NCR, a quote. A named user approves in the SyteLine form or in a confirmation step that calls the IDO as that user.

Sizing, limits and when not to bother

For 100 to 500 named users with 10 to 25 percent active per day, one to two inference GPUs in the 24 to 80 GB class usually cover peak load for a 8B to 32B model; a second node adds redundancy. The index for 100,000 to 1,000,000 document pages is typically tens of GB, not hundreds. Use the sizing calculator for your own numbers.

Limits: heavily customised schemas and user-defined fields need mapping work; older SyteLine 8.x builds may lack newer REST behaviour; calculated figures such as MRP results and costing roll-ups should come from IDO or reports, not be re-derived by the model. If you only need standard reports in natural language, Infor's own tooling on Infor OS may be enough.

Try it here, free

SyteLine IDO REST Request Generator

Open full tool

Fill in host, configuration, IDO, properties and filter to get ready-to-use REST calls for loading, updating and invoking methods on SyteLine IDOs.

Common pitfalls

  • !Querying _mst tables as a super user and returning rows from sites the asker cannot access.
  • !Letting the model write SQL against production instead of calling named, parameterised tools.
  • !Indexing attachments without carrying the record-level permissions into the index metadata.
  • !Re-deriving costs or MRP results in the model instead of reading the system of record.
  • !Writing back with direct UPDATE statements that skip IDO business rules and audit trails.

How an ERP-grounded AI assistant handles this

SyteRay and ERPray are built for this pattern on SyteLine: they read through IDOs and a reporting copy, show the query behind each answer, respect SyteLine roles and sites, and run on your own GPUs. Write actions stay behind human approval and IDO methods.

See ERPraySee SyteRay for SyteLine

Frequently asked questions

Can SyteLine AI run fully on-prem?

Yes. SQL Server, the Mongoose tier, the retrieval index and an open-weight model served by vLLM or Ollama can all sit on your network, including air-gapped, with model weights loaded through a transfer process.

Should the AI read IDOs or SQL?

Use IDOs for permission-aware record lookups and anything with business logic, and a read-only SQL reporting copy for aggregates. Both go through a tool server so the model never holds credentials.

Does it need CloudSuite Industrial?

No. On-prem SyteLine 8.x and CSI on your own servers work. Check which REST and ION features your build exposes; the SQL reporting-copy path works regardless.

How do I stop it showing other sites' data?

Apply the asker's SyteLine user groups and site list in the tool server, and filter reporting-copy queries by site_ref, so retrieval is scoped before the model sees any text.

Related

Advanced

How to Call SyteLine IDOs from an External Application

SyteLine exposes its IDO layer as a SOAP web service, commonly published through an IDORequestHandler endpoint, so an external .NET application, middleware platform, or script can Load, Update, Delete, and Invoke methods on the same IDOs the SyteLine client itself uses. You call it like any SOAP service: reference the WSDL, authenticate, and pass the IDO name, method, and parameters in the request.

Advanced

How to Add a Custom Method to a SyteLine IDO in C#

Custom IDO methods let you expose new server-side business logic - beyond the standard Load, Update, and Delete - as a named, callable operation from the SyteLine client, a script, or an external integration. You declare the method and its parameters on the IDO Collection, then implement it in an extension class that handles invoke calls for that method name.

Error fix

Fix a 401 Unauthorized error from Infor ION API

A 401 from ION API almost always means the credentials in the .ionapi file no longer match what ION API Gateway expects - not that the password is simply wrong. Check whether the Authorized App or service account behind the file was revoked, regenerated, expired, or issued for a different tenant, then re-test with a direct OAuth2 client_credentials call before touching any calling code.

Error fix

Fixing SyteLine's 'Object reference not set to an instance of an object' error

This is a generic .NET NullReferenceException surfacing through the SyteLine IDO Runtime, not a SyteLine-specific error code. It almost always means a form, script or IDO method referenced a field, row or object that came back null, usually after a customization, a missing related record, or a view/IDO method call before the form finished loading. Turn on detailed client logging and check the most recent customization or form event first.

Error fix

Diagnosing and fixing SyteLine session timeout errors

SyteLine session timeouts come from one of three independent layers: the IDO Data Service session timeout on the app server, the IIS/application pool idle timeout for the web (Mongoose Web) client, or a load balancer/proxy idle timeout in front of a CloudSuite hosted environment. Fixing the wrong layer is the most common mistake - you need to identify which layer is actually expiring the session before changing anything.

Error fix

Resolving SyteLine multi-site replication conflict errors

A replication conflict in SyteLine's multi-site architecture means the same record (commonly an item, customer, or BOM) was changed independently at two sites between replication cycles, and the replication engine could not automatically merge the two versions. Check the replication conflict log first to see which record and which fields collided, then decide which site's version should win before resuming the queue.

AI for ERP

AI for Infor SyteLine and CloudSuite Industrial

Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.

AI for ERP

An Air-Gapped Private LLM for SyteLine, Built for Defense Suppliers

Deploy a private LLM on an air-gapped network alongside Infor SyteLine for defense suppliers: no internet egress, ITAR and CMMC-aware architecture.

Stuck on Infor SyteLine (CloudSuite Industrial) on-prem?

Talk to engineers who work inside Infor SyteLine (CloudSuite Industrial) on-prem every week, and who build private AI that answers these questions from your own ERP data.

Talk to an ERP engineerBrowse ERP Help
All ERP Help articles

Keep exploring

Free tools

ERP fixes and how-tos

Runs with your ERP

Guides

AI on your ERP

Integrations

Comparisons

Software

TermsMongoose FrameworkCloudSuite IndustrialIDO (Intelligent Data Object)Air-Gapped AI