How to add an AI chatbot to Priority ERP
Short answer
A Priority chatbot answers questions from live Priority data through a controlled query layer, and respects who is asking. It can sit in an intranet page, a customer portal or a chat tool, and can run fully on-prem with an open-weight model.
Most Priority users do not want another screen. They want to ask 'where is order 12345' or 'do we have this part' and get an answer. A chatbot shortens that path, especially for occasional users such as sales reps, supervisors and customer service staff who forget the form names.
The important difference from a generic chatbot is grounding. Answers must come from Priority records at the moment of the question, shown with their document numbers, and refuse politely when the data is missing. A bot that guesses is worse than no bot.
There are two audiences with different rules. Internal staff can see more but need role limits. Customers and suppliers should see only their own documents, which makes identity mapping the main design problem.
What teams use it for
Internal order and stock helpdesk
Sales and service staff ask about order status, availability and lead times, and get answers with links to the relevant documents.
Customer order tracking portal
Customers sign in and ask about their own orders, shipments and invoices. The bot filters every query by the customer identity.
Supplier self-service
Suppliers ask which purchase orders are open and confirm dates, with replies recorded as proposals for the buyer.
Shop floor questions
Supervisors ask about work order status, missing components and routing steps from a tablet.
New-user guidance
The bot explains where to find a function in Priority and what a field means, using your own procedures documentation as a source.
Priority ERP integration surface
- The Priority OData REST service supplies live records for orders, parts, stock, purchasing and production.
- Priority users and profiles define internal permissions. For customers and suppliers, map portal identities to Priority customer or supplier numbers in your own layer.
- Documents such as procedures, data sheets and quality certificates may live in attachments or file shares, and can be indexed separately for retrieval.
- Priority offers its own web client and mobile options, and a chatbot can be embedded in an intranet page next to them rather than inside the Priority screens. Capabilities vary by version.
- For high-volume questions, a read replica or reporting copy of selected data can reduce load on the production server.
How it works
- 1
Define audiences and scopes
Decide who the bot serves first. Write down, per audience, which entities and fields are visible and which are not.
- 2
Build the query layer
Create tools for the common questions, each applying identity filters. The language model never writes raw filters against Priority.
- 3
Add document retrieval
Index procedures and approved documents with access labels, so the bot cites them and never mixes confidential files into a customer answer.
- 4
Host the model
Serve an open-weight model on a local GPU server for on-prem needs, or use a hosted model where policy allows. Keep the query layer identical either way.
- 5
Build the front end
Embed a chat panel in the intranet or portal. Show sources for every answer and a clear way to reach a human.
- 6
Test with real questions
Run a set of questions per audience, including attempts to see other customers' data, and fix failures before launch.
Example flows
Customer asks about a delivery
Trigger: Signed-in customer types 'when does my order arrive'
- Bot resolves the user to a Priority customer number.
- Query layer fetches that customer's open orders only.
- Bot picks the matching order and reads delivery status.
- Bot replies with date, carrier info if present, and order number.
Result: The customer gets an answer without calling support.
Supervisor checks a work order
Trigger: Supervisor asks what is blocking a work order
- Bot loads the work order and its components.
- It compares requirements with stock and incoming receipts.
- It lists the short components with expected dates.
Result: The supervisor knows which part to chase before the shift starts.
Keeping data on-prem
A self-hosted Priority server and a local model make a fully on-prem chatbot straightforward. Run the chat service, the query layer and the model on your network, point the query layer at the Priority OData endpoint, and host the front end on the intranet. For customer-facing use, place only the thin chat front end in the DMZ and keep the model and Priority behind it. This design leaves no ERP data with an external provider.
Security checklist
- Enforce identity filters in code for every customer and supplier question, never in the prompt.
- Label indexed documents by audience and filter retrieval by the asker's permissions.
- Rate limit and monitor the portal to prevent scraping through repeated questions.
- Store conversation logs with retention rules, and mask personal data you do not need.
Ways to get it done
Use the Priority web client and standard reports
Effort: None
Sufficient if staff are comfortable in Priority and questions are simple.
Generic chatbot platform with a custom Priority connector
Effort: Several weeks
Works for non-sensitive internal helpdesk use if hosted processing is acceptable.
Private chatbot built by a partner such as Netray
Effort: Scoped project
Fits regulated or customer-facing needs where identity scoping and on-prem models matter.
Pitfalls
- !Launching to customers before identity mapping is tested against adversarial questions.
- !Letting the bot answer from general knowledge when Priority has no record.
- !Ignoring the load that many chat questions place on the production server.
- !No handoff to a human, which frustrates users when the bot is stuck.
Frequently asked questions
Can the chatbot live inside the Priority screens?
That depends on your version and customization options. Most teams embed it in an intranet page or portal next to Priority, which is simpler and keeps the Priority install untouched.
How do we keep customers from seeing each other's data?
Map each portal login to a customer number and apply that filter inside the query layer on every call. Do not rely on instructions to the model. Test with deliberate cross-customer questions.
Does it work with Hebrew or other languages?
Many open-weight and hosted models handle multiple languages, including right-to-left scripts, with varying quality. Test with your actual part descriptions and notes before committing.
Can it run without internet access?
Yes. With a local model, a local query layer and an intranet front end, nothing needs outside access. Model weights are loaded once through a controlled transfer.
Is a chatbot better than dashboards?
They complement each other. Dashboards suit repeated monitoring, and a chatbot suits ad hoc questions from occasional users. If your needs are fixed reports, a dashboard may be enough.
Want AI chatbot 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