Specialist ERPsERP Platform

Priority ERP + private AI

AI for Priority ERP: grounded answers without leaving your data plane

Short answer

Adding AI to Priority ERP means building a connector layer over the Priority API or a read-replica of the underlying SQL Server or Oracle database, then grounding a model on that data with role-aware access controls. Priority shops run lean IT teams and heavily tabgen-customized screens, so the real work is mapping those custom fields into a documented semantic layer before any model sees them.

ERP: Priority ERP, Priority Cloud, Priority Discrete Manufacturing
Industries: Manufacturing, Electronics, Medical Device, Distribution
Written for: CIO

Discuss your Priority ERP environment See use cases

Priority ERP runs a large share of its install base as small IT teams supporting a system that has been reshaped over years of tabgen customization: custom screens, extra fields, and bespoke reports that only one or two people fully understand. That works fine day to day, but it means any new AI initiative has to start by re-discovering what the schema actually contains rather than assuming a textbook install.

Most Priority customers we talk to are not asking for a chatbot. They are asking for a way to stop being the bottleneck between the data sitting in Priority and the people who need an answer from it right now: a planner who wants open orders past due by vendor, a controller who wants a variance explained without waiting for the one person who can write a tabgen report.

Because Priority is used by manufacturers and distributors handling sensitive product, customer, or pricing data, and increasingly by electronics and medical device companies with export-control or regulatory exposure, the AI layer needs to sit inside the same trust boundary as the ERP itself rather than routing production data through a third-party SaaS chat product.

This page covers what actually has to be built: the connector into Priority (API or database), the semantic layer that makes tabgen customizations legible to a model, the deployment options that keep data under your control, and the questions worth asking before anyone starts.

What usually gets in the way

The problems we hear most from cio teams running Priority ERP.

Reporting stuck behind one report writer

Most non-trivial questions require a new tabgen report or a change to an existing MDI screen, and there is usually one person in the building who can do that work.

Every customization needs a Priority-certified hand

Tabgens, Tailor-Made screens, and BPM workflow changes are specialized enough that most in-house IT teams route them to a partner, which slows down anything exploratory.

Institutional knowledge lives in one or two heads

Lean Priority shops concentrate the meaning of custom fields and screen logic in whoever built them, with thin documentation to fall back on when they move on.

Cross-environment visibility is manual

Companies running separate Priority environments per subsidiary or site stitch together answers by exporting data into spreadsheets rather than querying across environments.

New hires take a long time to become self-sufficient

Priority's screen and menu vocabulary (MDIcons, tabgens, WBS-based project costing) is unfamiliar even to experienced ERP users, so onboarding to 'where do I find X' takes weeks.

Where AI earns its place in Priority ERP

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Natural-language query over sales, inventory, and WIP

Let planners and managers ask direct questions about open orders, inventory positions, and work-in-process without a new tabgen report for every variant of the question.

Touches: Priority API / ODBC read access to the underlying SQL Server or Oracle tables, including tabgen-defined custom fields

Outcome: Cuts ad hoc report requests to the one report writer from a weekly queue to occasional edge cases.

MRP exception triage

Summarize and rank the day's MRP action messages (shortages, past-due, expedite candidates) so planners work the highest-impact exceptions first instead of scrolling the full list.

Touches: MRP/planning tables, purchase order and works order records exposed via the Priority API

Outcome: Reduces time planners spend scanning raw MRP output before they start actually acting on it.

Purchase order and vendor follow-up automation

Draft and route vendor follow-up emails for late or at-risk POs, referencing the specific line, promised date, and history with that vendor.

Touches: Purchasing module records, vendor master data, prior correspondence logs

Outcome: Turns a manual weekly PO-chase task into a reviewed, ready-to-send draft list.

Quality and NCR documentation drafting

Draft non-conformance report narratives and root-cause sections from inspection and rejection data already captured in Priority, for a quality engineer to review and finalize.

Touches: Quality/inspection tables, item and lot records, tabgen-added quality fields

Outcome: Shortens time to a reviewable NCR draft from the point a rejection is logged.

Multi-environment consolidated reporting

Answer questions that span several Priority environments (by subsidiary or site) without manual spreadsheet consolidation, respecting each environment's own security groups.

Touches: Multiple Priority databases or API endpoints, mapped through a shared semantic layer

Outcome: Replaces a manual monthly consolidation exercise with an on-demand query.

Engineering change impact summaries

Summarize which open orders, on-hand inventory, and in-process jobs are affected when a BOM or routing changes, before the change is released.

Touches: BOM, routing, and open order tables, cross-referenced by item number

Outcome: Surfaces affected orders in minutes rather than a manual cross-check across screens.

New-hire onboarding assistant

Let new staff ask what a specific tabgen-customized field or screen means and where the underlying data comes from, grounded in your actual customization documentation.

Touches: Tabgen and Tailor-Made customization metadata, internal documentation, screen definitions

Outcome: Shortens the time a new hire needs before they can navigate customized screens unassisted.

Reference architecture

A Priority AI deployment is built as four layers sitting entirely inside your infrastructure: a connector that reads Priority through its API or a database replica, a semantic layer that translates tabgen-customized fields into documented, model-readable concepts, a model-serving layer running on your own GPUs, and a governance layer that enforces Priority's own security groups on every query.

1
ERP connectors
Read access via the Priority API (REST) for supported objects, or a replicated read-only copy of the SQL Server or Oracle backend for direct query access where the API does not expose what is needed.
2
Data and semantic layer
A documented mapping of tabgen-added fields, custom tables, and multi-environment schema differences into consistent business terms the model can reason over reliably.
3
Model serving
Open-weight models (Llama, Qwen, Mistral class) served with vLLM or Ollama on customer-owned or customer-controlled GPUs, sized to the concurrency the use cases actually need.
4
Retrieval and agents
Retrieval-augmented generation over the semantic layer plus structured query tools, with any write-back action (a follow-up email, an updated field) routed through a human approval step.
5
Governance and audit
Every query mapped to Priority's own user and security-group model, with full logging of what was asked, what data was touched, and what the model returned.

Integration notes for your ERP team

The Priority API (REST) covers most transactional objects; where it does not, a read-only replica of the SQL Server or Oracle backend fills the gap without touching production.
Tabgen-defined custom fields and Tailor-Made screens need to be inventoried and mapped explicitly; assuming a stock schema will produce confidently wrong answers.
Priority's WebSDK and BPM workflow module are useful hook points for triggering downstream actions (a drafted email, a flagged exception) once a human approves them.
Multi-company and multi-environment Priority setups need a mapping layer that reconciles field-naming differences across environments before questions can span them.
Security groups defined in Priority should be the single source of truth for access control in the AI layer, not a separate permission model maintained twice.
Any write-back to Priority (updating a field, creating a record) should go through the same validation Priority's own tabgen logic would apply, via the API rather than a raw database write.

Deployment options

Air-gapped on-prem

Priority customers in electronics, medical device, or defense-adjacent supply chains with strict data-boundary requirements

Model, retrieval layer, and database replica all run on hardware physically inside your network, with no outbound path for ERP data.

Private or sovereign cloud

Priority Cloud customers, or on-prem customers open to a dedicated single-tenant environment

Runs in a customer-controlled cloud tenancy rather than a shared multi-tenant AI service, keeping data isolated while avoiding new on-site hardware.

Hybrid

Multi-site or multi-subsidiary Priority estates with mixed constraints across locations

Sensitive sites run fully on-prem while others use a private cloud instance, unified through the same semantic layer and governance model.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

ISO 27001

Design the connector, storage, and logging layers to fit inside your existing ISMS scope rather than introducing an unmanaged external service.

GDPR (EU customers)

Keep personal data (customer, employee, HR-adjacent fields) inside the same jurisdiction and access controls as the source Priority environment, with no default retention beyond what governance requires.

Israeli Privacy Protection Regulations (Data Security)

Where the Priority estate or its data subjects sit in Israel, apply the same data-security controls (access logging, encryption at rest) the regulation expects of the source system to the AI layer.

SOC 2 (cloud deployments)

For private-cloud deployments, align logging, change management, and access review with your existing SOC 2 control set rather than standing up a separate framework.

Role-based access aligned to Priority security groups

Every model query inherits the requesting user's Priority security group so the AI layer cannot see data the user could not already see in Priority itself.

Where Netray fits

Custom build

Priority is not one of the ERPs Netray's packaged connectors currently cover, so integration is built as a scoped engagement against the Priority API and, where needed, a database replica, following the same connector-plus-semantic-layer pattern used elsewhere.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

-Inventory of tabgen customizations and custom fields in scope
-Data source decision (API vs. replica) per use case
-Security-group mapping plan
-Prioritized use-case shortlist

Phase 2 . 6-8 weeks

Pilot

-Working connector for one or two use cases
-Semantic layer covering the pilot scope
-Model serving stood up in the target environment
-Pilot results reviewed against defined success criteria

Phase 3 . Ongoing

Production

-Hardened connector and monitoring
-Full audit logging in place
-User training and rollout plan
-Support and change-management process for schema changes

Phase 4 . Ongoing

Scale

-Additional use cases added to the same platform
-Additional Priority environments or sites onboarded
-Periodic review of model and infrastructure sizing

Questions to ask any vendor, including us

A short list that separates real Priority ERP AI work from a chatbot demo.

Has the vendor actually worked with Priority's tabgen customization model, or are they assuming a generic ERP schema?
Will the connector read through the Priority API, a replica, or the live production database, and what is the performance impact of each?
What happens when a tabgen customization changes: does the semantic layer break silently or flag itself?
Where does the model run, and does any ERP data leave your network or tenancy at any point?
Is every write-back action gated behind a human approval step, and is that enforced technically or just by policy?
How is access control enforced: does it read Priority's own security groups, or is there a second permission system to maintain?
What is the actual support model once the pilot is over, and who owns the semantic layer long term?
Can you keep the work (connector, semantic layer, prompts) if you part ways with the vendor?

Frequently asked questions

Can AI work with Priority's tabgen customizations, or only a stock install?

It has to work with the customizations, because most Priority estates are heavily tabgen-modified. The practical approach is to inventory the custom fields and screens first, then build a semantic layer that documents what they mean, rather than assuming a textbook schema.

Does adding AI to Priority require sending data to a cloud AI vendor?

No. Open-weight models can be served on your own GPUs or in a private cloud tenancy, with retrieval built directly against your Priority API or database replica, so ERP data never has to leave your control.

Does Priority have built-in AI already?

Priority continues to add native platform features, but they are general-purpose rather than built around your specific tabgen customizations, multi-environment structure, or data residency requirements, which is where a purpose-built integration adds value.

How long does a first Priority AI pilot take?

A focused pilot on one or two use cases, such as natural-language query over open orders or MRP exception triage, typically runs 6 to 8 weeks after a 2 to 3 week discovery phase that inventories your customizations.

Can this integrate with a BPM workflow already built in Priority?

Yes. Priority's BPM module is a reasonable trigger point for downstream actions once a person approves an AI-suggested step, such as sending a drafted vendor follow-up or flagging an exception for review.

What happens across multiple Priority environments for different subsidiaries?

Each environment needs its own connector and security-group mapping, unified through a shared semantic layer, so a cross-environment question respects each subsidiary's own access controls rather than pooling everything into one flat view.

Is this only useful for large Priority customers?

No. Because Priority shops often run lean IT teams, mid-sized customers tend to see the most relief: the bottleneck of one report writer or one customization expert is exactly what a well-scoped AI layer is built to reduce.

Related guides

Ask your ERP anything

Natural Language Query for ERP Data: Ask SAP, Infor, or Oracle a Question in Plain English

See how natural language query over SAP, Infor, Oracle, and NetSuite data works: grounded text-to-SQL, role-based permissions, and a visible audit trail.

RAG + SQL + permissions

A Private LLM Grounded on Your ERP Data

How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.

Agents + approval gates

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.

ERP AI Buyer Guide

How to Choose an ERP AI Implementation Partner

A CIO checklist for picking an ERP AI implementation partner: the architecture questions to ask, red flags, pricing models, and what to demand in the SOW.

ERP AI Cost Guide

What ERP AI Actually Costs: A CFO's Guide

A CFO's guide to what ERP AI actually costs: GPU hardware, model licensing, integration and connector work, and realistic ongoing run-rate ranges.

QAD + on-prem AI

AI for QAD Adaptive ERP in automotive and industrial manufacturing

Add AI to QAD Adaptive ERP or Enterprise Edition for automotive and industrial manufacturing, grounded on QXtend and QAD's API layer, on-prem or private cloud.

Plan it with numbers

Free Tool

Talk it through with an engineer who knows Priority ERP

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.

Start the conversation See ERPray

All AI for ERP guides