# How to add a private AI layer to Infor Factory Track on-prem > Source: https://netray.co/erp-help/private-ai-layer-infor-factory-track-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind advanced ## System mfg-systems ## Erp Infor Factory Track (on-prem) ## Module Private AI / Shop Floor Data Architecture ## Query Infor Factory Track AI integration on-prem ## Alternate Queries - Factory Track shop floor data and AI - Infor Factory Track SQL Server reporting - local LLM for shop floor data collection ## 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. ## Steps ### Reference build for Infor Factory Track **Items:** - Identify the SQL Server instance, version and how it connects to the ERP. - Catalogue tables through INFORMATION_SCHEMA and confirm meanings with the Factory Track administrator. - Set up a readable secondary or scheduled copy and a read-only login limited to a view schema. - Create business-named views for jobs, operations, labour, scrap, and inventory moves. - Join to ERP read views for job, item and employee context. - Serve an open-weight model locally and expose parameterised queries via a tool server with role filters. - Pilot with supervisors, log every query, then review answers against the application reports. ## Sections ### Data access paths in Infor Factory Track **Body:** 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. **Code:** -- 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 = ''; GRANT SELECT ON SCHEMA::airead TO ai_reader; ### Reference architecture, including the air-gapped option **Body:** 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 **Body:** 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 **Body:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### Does this need a specific ERP? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** Yes. The SQL Server copy, vector index, tool server and model can all run without any outbound connection. ## Search terms Infor Factory Track AI, Factory Track SQL Server reporting, shop floor data collection AI, Factory Track M3 integration, barcode shop floor LLM, local LLM shop floor data, private AI MES on-prem, Factory Track read-only replica, Infor Factory Track data access --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json