AdvancedInfor Factory Track (on-prem)Private AI / Shop Floor Data Architecture

How to add a private AI layer to Infor Factory Track on-prem

Question
Infor Factory Track AI integration on-prem

Also searched as

  • Factory Track shop floor data and AI
  • Infor Factory Track SQL Server reporting
  • local LLM for shop floor data collection

Short answer

Infor Factory Track captures shop floor and warehouse transactions by barcode and posts them to the connected ERP (commonly Infor M3 or SyteLine; confirm yours), keeping its working data in a SQL Server database. A private AI layer should read that database through a read-only secondary or copy, discover the schema from INFORMATION_SCHEMA rather than guessing names, join it to ERP data for context, and run an open-weight model locally. Corrections to transactions go through the supported application screens or ERP interfaces after approval.

Applies to: Infor Factory Track on-prem with SQL Server, connected to M3, SyteLine or another supported ERP; schema and posting behaviour depend on release and configuration.

Reference build for Infor Factory Track

  1. 1Identify the SQL Server instance, version and how it connects to the ERP.
  2. 2Catalogue tables through INFORMATION_SCHEMA and confirm meanings with the Factory Track administrator.
  3. 3Set up a readable secondary or scheduled copy and a read-only login limited to a view schema.
  4. 4Create business-named views for jobs, operations, labour, scrap, and inventory moves.
  5. 5Join to ERP read views for job, item and employee context.
  6. 6Serve an open-weight model locally and expose parameterised queries via a tool server with role filters.
  7. 7Pilot with supervisors, log every query, then review answers against the application reports.

Data access paths in Infor Factory Track

Factory Track is a data collection layer: operators scan jobs, operations, items and locations on terminals or handhelds, and the application records and posts those transactions to the ERP. Its own data sits in SQL Server. Because table names and structures vary by release and by configuration, we do not hard-code them here. Start with INFORMATION_SCHEMA.TABLES and COLUMNS, identify the transaction and master tables the application screens read, and document them with the Factory Track administrator.

For anything that touches the ERP side, use the ERP's own supported interfaces. For M3 that means its API transactions through the Infor integration layer, and for SyteLine its documented IDO and ION interfaces, never direct table writes. The assistant is most useful when it can join floor transactions with ERP job, item and employee context, so plan both data sources into the design from the start.

-- Discover the transaction tables in the Factory Track database (SQL Server)
SELECT t.TABLE_SCHEMA, t.TABLE_NAME, c.COLUMN_NAME, c.DATA_TYPE
FROM INFORMATION_SCHEMA.TABLES t
JOIN INFORMATION_SCHEMA.COLUMNS c
  ON c.TABLE_SCHEMA = t.TABLE_SCHEMA AND c.TABLE_NAME = t.TABLE_NAME
WHERE t.TABLE_TYPE = 'BASE TABLE'
ORDER BY t.TABLE_NAME, c.ORDINAL_POSITION;

-- Read-only login for the assistant
CREATE LOGIN ai_reader WITH PASSWORD = '<set-securely>';
GRANT SELECT ON SCHEMA::airead TO ai_reader;

Reference architecture, including the air-gapped option

A workable private AI layer for Infor Factory Track has six parts. First, a read-only data path: SQL Server views over a replica or reporting copy so production is not queried. Second, a retrieval index over the documents and attachments people actually search, built with an open embedding model and stored in a vector database that runs on your servers. Third, a tool server, for example an MCP server, that exposes a short list of approved read actions with typed parameters. Fourth, an open-weight model served with vLLM or Ollama on local GPUs. Fifth, an identity layer that carries Factory Track role and plant into every request. Sixth, an audit log of who asked what, which queries ran and which documents were retrieved.

The model never receives a database connection string. It asks the tool server to run a named action, and the tool server builds the parameterised query, applies the user's visibility filter and returns rows. This keeps free-form SQL generation out of production paths and makes every answer traceable to a query you can show the user. For an air-gapped site, all six parts run with no outbound route; model weights and updates arrive on approved media and are scanned and checked before use.

Use a readable secondary (Always On availability group), a log-shipped standby or a scheduled copy for the assistant. Shop floor terminals depend on the database being responsive, and a long analytical query on the primary can slow scanning. Floor transactions are time-sensitive, so keep replica lag low if you want near-real-time answers on job progress.

Permissions: the assistant must never show more than the user may see

Factory Track roles control what terminals and users can do, and employee-level labour data is sensitive. In the assistant, separate roles clearly: supervisors may see labour by employee, general users may see only job and quantity data. Resolve the user from your directory, map to a role in the tool server, and expose labour views only to the roles allowed.

Where the ERP carries its own site or plant restrictions, apply the same filters to joined ERP data. SQL Server row-level security can enforce plant filters inside the database as a second layer.

Write-back only through supported interfaces

The assistant should not post or edit floor transactions. If a supervisor wants to correct a mis-scanned quantity, the assistant can prepare the correction request with the evidence, and the supervisor performs it in Factory Track's own screen or through the ERP's supported interface. That keeps the application's validation and the ERP's audit trail intact.

Sizing, phased rollout and honest limits

Sizing depends on concurrency, not on headcount. A pilot of 10 to 20 users with a 7B to 14B class model can run on one workstation-class or datacentre GPU with 24 to 48 GB of memory. A site with 100 to 300 named users, of whom a third use it daily, often needs one to four GPUs depending on model size and answer length. Retrieval indexes for tens of thousands of documents are typically in the single to low double digit gigabytes. Use the sizing calculator for your own numbers and treat results as ranges.

Roll out in three phases. Phase one is read-only questions over a small set of views and documents, with every answer showing the query or sources. Phase two adds drafts, such as a summary, a message or a prepared transaction, that the user reviews but that nothing posts. Phase three adds approved actions through Infor Factory Track's supported interfaces, always under the approving user's identity, with an audit record.

Without published schema documentation for your release, the dictionary must be built by looking at the database and the application together. It is slower than for ERPs with well-known tables.

If the question is only 'what did operator X scan', the application's own reports answer it. The value of an AI layer is in joining floor data with ERP data and documents, which needs both sources available and consistent.

Try it here, free

Infor Factory Track Private AI Layer Blueprint Generator

Open full tool

Fill in your Infor Factory Track version, database, hosting and use cases and get a shareable architecture plan for a private AI layer.

Common pitfalls

  • !Assuming table names from another release or from a forum post.
  • !Running analytical queries on the primary that terminals depend on.
  • !Exposing employee-level labour data to all assistant users.
  • !Allowing any write path from the assistant to posted transactions.
  • !Comparing floor data and ERP data without handling posting delays.

How an ERP-grounded AI assistant handles this

ERPray and Netray's custom build work follow this pattern: read-only by default, the query is shown to the user, Infor Factory Track roles and visibility are respected, and everything runs on your hardware with open-weight models. Where a vendor's own AI or standard reporting already answers the question, we say so; the private layer earns its place for cross-system questions, document search and sites that cannot send data off premises.

See ERPray

Frequently asked questions

Does this need a specific ERP?

No, but Factory Track is commonly paired with Infor M3 or SyteLine and the join between floor and ERP data is where most of the value comes from. With another supported ERP, use that system's documented read access.

Can we get real-time answers?

Near-real-time, if the readable secondary lag is low. Scanning terminals use the primary, so the assistant should always read from the secondary.

How do we protect labour data?

Expose labour views only to roles allowed to see employee-level detail, and apply plant filters using SQL Server row-level security as a second layer.

Is this air-gap capable?

Yes. The SQL Server copy, vector index, tool server and model can all run without any outbound connection.

Related

Advanced

How to add a private AI layer to Infor XA on-prem

Infor XA keeps its data in Db2 for i on IBM i, so the safest way to add AI is a read-only reporting copy or logical-file access over JDBC or ODBC, a retrieval index over documents, a small tool server that exposes approved queries, and an open-weight model served on local GPUs. Nothing has to leave the building, and any write-back goes through the supported XA transaction programs after a person approves it.

Advanced

How to add a private AI layer to Infor LX / BPCS on-prem

BPCS and Infor LX run on IBM i with their data in Db2 for i, in files that carry short coded names by module. A private AI layer reads those files through read-only SQL views over a replica, indexes documents and attachments separately, exposes approved queries through a tool server, and serves an open-weight model on local GPUs. Writes, if any, go through the supported transaction programs with human approval.

Advanced

Infor Factory Track for M3: Shop Floor Data Collection Explained

Infor Factory Track is a shop floor data collection and execution product used with M3 so that operators report production, time and materials at the machine instead of on paper or at an ERP terminal. It reads released manufacturing orders from M3 and writes reported quantities and times back, so M3 costing and planning see actuals.

How-to

How to Send Production and Labor Reporting from MES to ERP

Treat the ERP work order as the system of record for cost and quantity, and the MES as the system of record for what physically happened. Send one confirmation message per operation (or per shift or lot) containing work order, operation sequence, good quantity, scrap quantity with reason, and labor start/stop per employee and work center, post it through the ERP's supported transaction API, and make the message idempotent so a retry never double-posts.

How-to

How to Calculate OEE from MES Data and ERP Standards

OEE equals Availability times Performance times Quality. Availability comes from MES run and stop events against planned production time, Performance compares actual output to the ideal cycle time (usually the routing standard from the ERP), and Quality is good units divided by total units. The numbers are only trustworthy if planned time, ideal cycle time and the good/scrap split are defined once and used consistently.

Advanced

ISA-95 and B2MML: How to Integrate ERP with MES

ISA-95 defines the boundary between business systems (Level 4, the ERP) and manufacturing operations (Level 3, the MES) and the information that crosses it. B2MML is the XML implementation of those models. In practice you exchange a ProductionSchedule from ERP to MES, and ProductionPerformance, plus material and equipment information, back, mapping each element to your ERP's work order and confirmation APIs.

AI for ERP

Infor M3 AI: A Practical Path from MI Programs to a Private Assistant

Infor M3 AI explained: grounded natural-language answers over MI programs and MEC, agents for distribution and manufacturing, on-prem or EU private cloud.

Stuck on Infor Factory Track (on-prem)?

Talk to engineers who work inside Infor Factory Track (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