How to add AI agents to Priority ERP
Short answer
Build AI agents on Priority by exposing a small set of OData-backed tools (read first, writes behind approval), then letting a model plan multi-step work over them. The model can run on your own GPUs next to the Priority application server, so no ERP data leaves the plant.
Priority is popular with mid-size manufacturers, electronics and food producers that want one system covering sales, purchasing, inventory, production and finance. Teams on it often have a lean IT group, a few power users who know the forms inside out, and a backlog of small jobs nobody has time for: chasing late purchase orders, checking why a work order is short a component, answering the same customer status questions every morning.
An AI agent is a good fit for that kind of work because the steps are repetitive but need judgement at the edges. A useful agent does not replace the planner. It reads the data the planner would read, drafts the action the planner would take, and waits for a click before anything is written back to Priority.
The practical question is where the agent touches Priority. The answer is the OData REST layer, not the database. Priority forms are exposed as entities, they carry the business logic and the user's permissions, and they are the supported way in. Agents built on that layer survive version upgrades far better than agents that query tables directly.
What teams use it for
Late purchase order expediting
The agent lists open purchase orders past their due date, groups them by supplier, checks whether the missing parts gate a released work order, and drafts a reminder email per supplier for the buyer to approve.
Shortage triage for work orders
Before a production run, the agent compares the BOM against on-hand and incoming stock, ranks shortages by the work orders they block, and proposes which supplier call or substitute part to try first.
Customer order status desk
Sales support asks in plain language where an order stands. The agent reads the sales order, linked work orders and delivery notes, and answers with the source rows so the person can verify it.
Price and cost variance review
After goods receipts, the agent flags purchase prices that moved beyond a tolerance versus the last receipt and drafts a note for procurement, leaving the price list untouched.
Master data hygiene
The agent scans the part catalog for duplicates, missing units, missing planning parameters and inactive parts still on live BOMs, and produces a worklist for the data owner rather than editing records.
Month-end exception sweep
Finance gets a daily list of unposted documents, receipts without invoices and invoices without receipts, each with a suggested next step and a link to the form.
Priority ERP integration surface
- Priority exposes forms as OData v4 entities through its REST service, typically under a path of the form /odata/Priority/<tabula.ini>/<company>/<ENTITY>. Sales orders, purchase orders, customers, suppliers and parts each map to a form entity, with sub-forms reachable as nested collections.
- Authentication is usually basic auth with a Priority user, or an application ID and key sent as request headers, depending on version and whether you run Priority Cloud or a self-hosted server. Confirm which your build supports.
- Business logic lives in the form triggers and procedures. Writing through the OData entity runs those triggers, which is what you want an agent to do, rather than inserting rows into the SQL Server tables.
- Priority procedures and the interface/loading mechanism can be called for bulk or document-style operations, and the Web SDK offers a JavaScript route for browser-side extensions. Names and availability vary by version.
- Reports and dashboards defined in Priority can often be exported, which is a cheap way to give an agent a stable, pre-filtered dataset without hand-building queries.
How it works
- 1
Pick two or three jobs, not an assistant for everything
Choose workflows with a clear owner and a measurable outcome, such as expediting or shortage triage. A narrow job is easier to test and easier for the planner to trust.
- 2
Create a dedicated Priority user for the agent
Give it a profile limited to the forms it needs. Read-only for the first phase. This makes the audit trail honest and keeps Priority's own permission model in force.
- 3
Wrap OData calls as named tools
Write functions such as list_open_pos, get_bom, get_stock_by_warehouse and get_order_status. Each returns trimmed JSON with the document numbers the user will recognize, and each enforces filters and row limits.
- 4
Run a model locally and give it the tools
Serve an open-weight model with vLLM or Ollama on a GPU server in your network. The agent loop calls tools, reads results, and decides the next call, with a hard cap on steps.
- 5
Add write tools only as drafts
A write tool should create a proposal record or a message, not change a purchase order. A human approves in a small review screen, and only then does a separate service call the Priority entity.
- 6
Log every call and replay failures
Store the prompt, tool calls, Priority responses and the approver. When a planner disputes an answer, you can show exactly which rows the agent saw.
Example flows
Morning expedite list
Trigger: Scheduled at 06:30 on weekdays
- Agent pulls open purchase order lines with a due date before today.
- For each line it reads the part, the supplier and any released work orders that consume the part.
- It ranks lines by production impact and groups them per supplier.
- It drafts one email per supplier and a summary for the buyer.
Result: The buyer reviews a ranked list and sends approved emails in one pass, instead of building the list by hand.
Short component explanation
Trigger: Planner asks why work order is short
- Agent loads the work order and exploded BOM.
- It reads stock and incoming supply for each component.
- It identifies the short part and the purchase order that should cover it.
- It returns the cause with the rows used, plus a proposed action.
Result: The planner sees the cause in seconds and the evidence to check it.
Keeping data on-prem
Priority is frequently self-hosted on Windows with SQL Server, and many customers keep it that way for data residency or because of connectivity at the plant. The agent stack follows the same pattern: a small GPU server on the same network segment, an open-weight model served locally, an agent service that talks to the Priority OData endpoint over the LAN, and a review UI. Nothing needs to call a public API. For air-gapped sites, bring model weights in through a controlled transfer and keep the agent logs on internal storage. Size the GPU for the smallest model that passes your test questions rather than the largest one available.
Security checklist
- Use a dedicated Priority user with the narrowest profile that works, and keep credentials in a secrets store, never in prompts.
- Keep tools read-only until the agent has run in shadow mode for weeks, and gate every write behind a named human approver.
- Treat text from emails, notes and remarks fields as untrusted input that could contain instructions, and never let it choose which tool to call.
- Log tool calls and approvals to storage the agent cannot edit, and retain them per your own records policy.
Ways to get it done
Priority's own automation and AI features
Effort: Low, mostly configuration
Good when your need is a rule, an alert or a standard report. Check what your Priority version and licence include before building anything.
Build in-house on OData
Effort: A few weeks for a first read-only agent
Works if you have a developer comfortable with REST and a local model runtime, and the scope is one or two workflows.
Work with a partner such as Netray
Effort: Scoped pilot, then expand
Useful when you want on-prem models, an approval workflow and an evaluation set without staffing it yourself. Priority consultants can supply the process knowledge.
Pitfalls
- !Letting the agent query SQL Server tables directly, which skips triggers and breaks on upgrades.
- !Returning whole entities to the model, which wastes context and leaks fields the task does not need.
- !Skipping company and warehouse filters, so the agent answers from the wrong legal entity.
- !Automating a process that the team itself does inconsistently, so there is no correct answer to test against.
- !Granting write access early because the demo looked good.
Frequently asked questions
Does the agent need direct database access to Priority?
No, and it is better without it. Use the OData REST service so that form triggers, validations and user permissions all apply. Direct SQL reads can be acceptable for reporting replicas, but writes should always go through the supported entities.
Can this run if my Priority server is on-premises?
Yes. The agent service and the model both run on your network and call the Priority OData endpoint locally. You only need outbound internet if you choose a hosted model, which is optional.
Which tasks should an agent do first?
Start with read-heavy, repetitive work such as late purchase order lists, shortage explanations and order status. These are easy to verify and carry little risk. Add drafted writes after the team trusts the reads.
How do we stop the agent changing the wrong record?
It never writes directly. It creates a proposal that a named user approves, and a separate service performs the change using a limited Priority user. Every proposal stores the data the agent saw so it can be checked afterwards.
Do we need a large GPU?
Usually not. Many tool-calling workflows run well on a mid-size open-weight model on a single server GPU. Test with your real questions and choose the smallest model that meets your accuracy bar.
Want AI agents working on your Priority ERP?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment