AdvancedJobBOSS (classic, on-prem)AI integration / SQL Server read access

How to Add a Private AI Layer to Classic JobBOSS On-Prem

Question
how to add AI to JobBOSS on-prem

Also searched as

  • JobBOSS SQL Server AI assistant
  • JobBOSS AI integration without cloud
  • private LLM for JobBOSS shop data

Short answer

Classic JobBOSS stores its data in a Microsoft SQL Server database, so a private AI layer can read job, operation, material, customer and delivery data through a read-only login on a restored or replicated copy. Documents stay in a local index, the model runs on your own GPU, and any change to JobBOSS goes through its own screens or supported import tools after a person approves.

Applies to: Classic on-premises JobBOSS (the SQL Server based desktop product), not JobBOSS2 or Epicor-hosted offerings; verify your version and schema

Steps to add a private AI layer to JobBOSS (classic, on-prem)

  1. 1Confirm the product is classic JobBOSS on SQL Server and note the SQL Server edition and version; Express editions have size and feature limits that matter for replicas.
  2. 2Restore last night's backup to a separate SQL Server instance or enable log shipping, so the assistant reads a copy and not the live database.
  3. 3Create a SQL login and database user with SELECT on only the tables and views the assistant needs, and deny everything else.
  4. 4Build views in a separate schema that rename cryptic columns, expand status codes and apply row filters, then document each column.
  5. 5Index job packets, drawings, material certificates and inspection records into a local vector store with customer and job metadata.
  6. 6Serve an open-weight model locally with vLLM or Ollama and expose approved read actions through a tool server with full audit logging.
  7. 7Map each JobBOSS user to a role and scope views by role; hide cost and rate columns from non-management roles.
  8. 8Phase the rollout: read-only status questions, then document Q and A and drafts, then approved actions through supported routes.

How JobBOSS data can be reached

Classic JobBOSS keeps its operational data in SQL Server. Core tables include Job, Job_Operation and Material_Req for work in progress, plus Customer, Delivery, and the purchasing and invoice headers and details. The exact column names and status values depend on your version, so verify them against your own schema before building views.

A read-only SQL login on a restored copy is the simplest path. Grant SELECT on specific objects, not db_datareader on everything, so new tables with sensitive content are not exposed by default. Put the assistant's views in their own schema so the application's tables stay untouched.

Do not insert or update rows with SQL. JobBOSS calculates costs, statuses and quantities in the application, and direct writes can leave jobs in states the client cannot display or close correctly.

-- Dedicated read-only login (run on the replica)
CREATE LOGIN ai_reader WITH PASSWORD = '<set from your vault>';
USE [<your JobBOSS database>];
CREATE USER ai_reader FOR LOGIN ai_reader;
GRANT SELECT ON dbo.Job TO ai_reader;
GRANT SELECT ON dbo.Job_Operation TO ai_reader;
GRANT SELECT ON dbo.Customer TO ai_reader;
-- Example read (verify column names and status values in your schema)
SELECT TOP 50 Job, Part_Number, Status, Customer
FROM dbo.Job
WHERE Status = 'Active'
ORDER BY Job;

Reference architecture

A small shop does not need exotic infrastructure. Restore the nightly backup to a second SQL Server instance (or log-ship it), put a vector store such as pgvector or Qdrant on a modest server, and run one GPU workstation or server for the model. The tool server sits between the model and SQL Server and exposes a handful of parameterised reads such as open jobs by customer, late operations by work center and material on order for a job.

Every question, tool call and row count is written to an append-only log. The log is useful for tuning and for showing a customer or auditor that the assistant only read what a user was entitled to see.

For plants handling controlled drawings or technical data, the same stack can run fully air-gapped. The architecture keeps the data inside the customer's boundary, which helps the customer meet its own obligations; it does not itself confer any certification.

Permissions and data scope

JobBOSS has its own user and security groups, but the assistant's SQL login is a single account. So scope has to be enforced in the tool server: identify the person through your directory, map them to a role, and allow only the views that role needs.

Rates, burden, cost and margin fields should be limited to management and finance roles. Customer-specific restrictions, such as drawings that only certain staff may view, are best handled with metadata tags on index chunks and a retrieval filter applied before the model sees any text.

Test by logging in as a machinist and as an estimator and asking the same questions. The answers should differ exactly where the roles differ.

Write-back, sizing and phased rollout

Treat JobBOSS as read-only for the first release. Where an action is worth automating, such as logging a delivery date change, let the assistant prepare the entry and have a person make it in the client, or use an import tool or integration the vendor supports for your version.

A shop with 20 to 80 named users usually fits on one 24 GB class GPU with a 7B to 14B model, and often needs less if usage is light. Document volume of tens of thousands of pages produces an index well under a gigabyte or two.

Phase one covers job status, late operations and shortages for 3 to 4 weeks. Phase two adds document retrieval and drafted supplier or customer messages. Any write action is a separate, later decision.

Honest limits

Classic JobBOSS is an aging product line and the vendor's direction has moved to newer offerings, so avoid investments that only make sense if you stay on it for a decade. Schema documentation may be thin, and the first weeks often go to mapping columns and statuses.

If the shop only needs a handful of recurring reports, the built-in reports and a Power BI or SQL Server Reporting Services dashboard may serve better than an AI assistant. The assistant earns its place with ad hoc questions and document retrieval.

Try it here, free

JobBOSS Classic AI Assistant Sizing and Value Calculator

Open full tool

Estimate peak concurrency, GPU count, index size, hours saved and payback for a private AI assistant on JobBOSS Classic.

Common pitfalls

  • !Granting db_datareader on the whole database instead of SELECT on specific objects.
  • !Querying the live database during production hours.
  • !Assuming status values without checking them in your own schema.
  • !Showing labor rates and cost fields to every role.
  • !Writing to JobBOSS tables with SQL instead of using the client or a supported import.

How an ERP-grounded AI assistant handles this

ERPray's read-only pattern applies here: a restricted SQL login on a copy, the query shown to the user, and role-based scope. Netray can build the views, tool server and document index for a JobBOSS shop and host the model on your own GPU.

See ERPray

Frequently asked questions

Does classic JobBOSS use SQL Server?

Yes, the classic on-premises product stores its data in Microsoft SQL Server. Confirm your edition and version, and note that JobBOSS2 is a different product with a different architecture.

Is it safe to give an AI assistant a SQL login?

It is safe when the login is read-only, limited to specific objects, pointed at a restored or replicated copy, and wrapped by a tool server that logs every call and enforces role scope.

Can the assistant close jobs or update dates?

Not in the first release. Let it draft the change and have a user enter it in JobBOSS or through a vendor-supported import. Direct SQL writes can corrupt costs and statuses.

What hardware does a small shop need?

Often one GPU workstation with 24 GB of memory running a 7B to 14B open-weight model, plus a small server for SQL Server and the vector store.

Related

How-to

How to Close a Job in JobBOSS2

A job in JobBOSS2 will not close cleanly until every routing operation is marked complete, all material has been issued or returned, and all labor and cost transactions are posted. Review the job's Work In Process detail first, clear any open items, then change the job status to Complete and run final job costing before it is locked.

How-to

How to Create a Quote in E2 Shop System

A quote in E2 Shop System starts with a header identifying the customer and part, then adds routing operations with time and rate, material and outside processing costs, and a markup to reach a sell price. Once accepted, the quote converts directly into a job or sales order so the estimate carries forward as the job's cost basis.

Advanced

How to Add a Private AI Layer to QAD Enterprise Edition On-Prem

QAD EE runs on a Progress OpenEdge database, which can be read through the OpenEdge SQL-92 engine over JDBC or ODBC without touching the 4GL application. A private AI layer reads a replica or reporting copy, indexes documents locally, serves an open-weight model on your own GPUs, and writes back only through QXtend or another supported QAD interface with human approval.

Advanced

How to Add a Private AI Layer to Global Shop Solutions On-Prem

Global Shop Solutions keeps jobs, routings, inventory, purchasing and quality data in one database that can be read through ODBC or the vendor's report and export tools. A private AI layer works from a read-only copy, builds a documented semantic layer over the tables you actually use, serves an open-weight model locally, and writes back only through vendor-supported import or API routes with approval.

Advanced

How to Add a Private AI Layer to E2 Shop System On-Prem

E2 Shop System holds quotes, orders, jobs, routings, inventory and purchasing in a database you host yourself. A private AI layer reads a copy through a restricted account, exposes it through documented views, indexes quotes and job documents locally, runs an open-weight model on your own GPU, and leaves changes to E2's own screens or supported interfaces with a person approving.

Error fix

E2 Shop System Error 5093: Causes and How to Troubleshoot

We could not find an authoritative public definition of E2 error 5093, so treat any single-cause answer with caution. In practice, numbered E2 errors raised at login or while opening a module come from the client talking to the database: a changed server name, a SQL permission or login problem, a missing or mismatched driver, or a network or firewall change. Isolate which with the checks below and give Shoptech support the exact context.

AI for ERP

AI for ECI JobBOSS2 and E2 Shop System

Add AI to ECI JobBOSS2 or E2 Shop System for faster quoting, tighter scheduling, and shop-floor answers, without sending your job data to the cloud.

AI for ERP

AI Agents for ERP, Running On-Prem

A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.

Stuck on JobBOSS (classic, on-prem)?

Talk to engineers who work inside JobBOSS (classic, 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

Guides

AI on your ERP

Integrations

Software