Permission Policies
Restrict what data assigned users can read and modify through Operator
Permission Policies let instance admins define exactly which parts of the ERP.net data model an Operator user is allowed to access — on top of ERP.net's own security. They are managed per ERP.net instance from Manage Instance Users → Policies.
Why Use Permission Policies?
ERP.net's built-in roles control access at the database level, but they apply uniformly to everyone using a given login. Operator policies let you:
- Give a sales rep AI access only to CRM entities, even though their ERP.net login can technically read more.
- Restrict a client user to a single namespace such as
Logistics.Sales. - Allow a controller to read finance data but block any update through the AI.
- Force certain users to stay on-topic (no general chit-chat with the AI — see Allow off-topic conversations below).
Policies are enforced on top of ERP.net's own security. ERP.net checks always run; the policy simply adds a second filter that blocks access to anything outside the granted scopes.
Who Can Manage Policies?
Only Instance Admins (instance role 40) can create, edit, delete, and assign Permission Policies. Other users see the assigned policy on their own account in read-only form.
Accessing the Policies Page
- Open the user menu and choose Manage Instance Users.
- Switch to the Policies tab.
You will see the list of policies defined for the current ERP.net instance, plus how many users each policy is assigned to.
Creating or Editing a Policy
Click New Policy (or the pencil icon on an existing policy). Each policy has:
| Field | Description |
|---|---|
| Name | Short label shown when assigning the policy to users (e.g. Sales Reps, Read-only Finance). |
| Description | Optional notes for other admins explaining the intent. |
| Allow off-topic conversations | Master switch that controls Topic Guard for assigned users — see below. |
| Scope tree | Visual tree of all ERP.net namespaces and entities the policy grants access to. |
Working with the Scope Tree
The scope tree is the heart of a policy. It mirrors the ERP.net data model — namespaces (e.g. Crm, Logistics, Finance) at the top, with sub-namespaces and individual entities underneath.
- Tick a checkbox to grant access to that node and everything beneath it. Ticking
Crmgrants the entire CRM namespace. - Expand a branch with the chevron to pick individual children instead.
- Indeterminate state (◪) means some descendants are granted but not all — useful for spotting partial coverage at a glance.
- Read / Update toggle appears next to each granted node. Update automatically includes create, update and delete; Read is query-only.
- Search box filters the tree in real time and auto-expands matching branches so you can find an entity quickly.
When you save, Operator collapses your selection to the smallest equivalent set of scope entries. For example, if you tick every entity inside Crm, the saved policy stores a single Crm.* entry instead of dozens of individual ones. Re-opening the policy expands them back into the tree.
Allow off-topic conversations
The Allow off-topic conversations switch controls whether assigned users can chat with the AI about non-work themes (the weather, general knowledge questions, casual conversation, etc.).
- On (default) — users can freely choose whether to enable Topic Guard in their own Settings → AI-enhanced.
- Off — Topic Guard is forced on and locked for every user assigned to this policy. Their Settings dialog shows the toggle as disabled with a hint that the instance admin controls it. The AI will politely refuse anything unrelated to ERP.net or the user's work.
This is the right setting for client-facing or shared-account scenarios where you want to keep AI usage strictly on-topic.
Assigning a Policy to a User
- Go to the Users tab in Manage Instance Users.
- Locate the user and use the Policy dropdown in their row.
- Pick a policy or choose No policy to remove the restriction.
A user without a policy keeps unrestricted Operator-side access — ERP.net's own security still applies.
Policy assignment changes are recorded in the instance Audit Log, so you can always trace who changed what and when.
How Enforcement Works
Whenever an assigned user runs a tool that reads or writes ERP.net data, Operator:
- Determines the entity being accessed (e.g.
Crm.Customers). - Looks up the user's policy and checks whether the entity is covered.
- For writes, also confirms the policy grants Update on that scope.
- Blocks the call with a clear message if the entity is outside the allowed scopes.
Read-only policies still let users see business data the AI returns — they just can't trigger create/update/delete operations through the AI. To restrict reads, simply leave the relevant branches unticked.
The AI is also informed about restrictions at discovery time — when it looks up an entity (for example to plan a query), the response already tells it whether the user has full, read-only, or no access. This way the AI can warn the user proactively instead of attempting a call that will be denied, and it knows not to keep retrying similar lookups.
Tips
- Start with broad namespace ticks (e.g. all of
Crm) and only narrow down where it matters. Saved policies are easier to audit when they use namespace-level entries. - Use the description field to record why a policy exists — future admins will thank you.
- Combine Allow off-topic conversations = Off with a tightly-scoped policy to create a strict, business-only AI experience for client users.
- If a user reports being blocked from data they expect to access, check both their ERP.net role and their assigned policy.