Roles & Permissions

Permissions in Primentra are always granted through roles. There are no per-user permissions. To know what a user can do, look at their roles.

Roles live in Settings → Access Management → Roles.

The permission matrix for a role, with CRUD toggles per model, entity and attribute(click to enlarge)

Create a role

Click New role.
On the Settings tab, enter a Role name and an optional Description.
Choose a Role type if the role needs one (see below).
Click Create role.
Open the Members tab and tick the users who belong to the role.
Click Save.
Open the Permissions tab and grant access.

The Permissions tab stays disabled until the role is saved. It is labeled *save first* until then.

Role type

Two checkboxes on the Settings tab change what the role means.

Administrator — members get full access to everything and bypass every permission check. The permission matrix is ignored for them.
Approver — members can approve changes. Only users in an Approver role can be assigned as approvers on an entity.

An Administrator role shows an amber banner on the Permissions tab: *Administrator role — permissions do not apply*.

Permission scopes

Permissions cascade through three levels.

Scope	Effect
Model	Sets the default for every entity in the model
Entity	Overrides the model default for one entity
Attribute	Overrides entity and model for one field, Read or Write only

A badge with ↑ means the permission is inherited, not set directly. Click the × button next to the CRUD toggles to clear an override and fall back to inherited.

CRUD permissions

At model and entity scope, five toggles control access.

Toggle	Grants
C	Create — add rows, import data, paste rows
R	Read — view data in the grid and export it
U	Update — edit cell values, bulk edit, fill handle
D	Delete — remove rows, purge entity data
Mod	Moderator — full CRUD plus entity and model configuration

Three rules apply automatically:

Turning on C, U, or D also turns on R. You cannot write what you cannot see.
Turning on Mod turns on all four CRUD toggles.
Turning off R turns off C, U, and D.

D does not need U, and C does not need U. The four operations are otherwise independent.

Effective combinations

Combination	What the user can do	Typical use
None	No access — the entity is invisible	Restricted data
R	View and export only	Viewers, auditors, reporting
CR	View and add rows	Data entry that cannot correct itself
RU	View and edit existing rows	Maintenance teams
RD	View and delete rows	Cleanup roles
CRU	View, add, and edit	Safe default for editors
CRD	View, add, and delete, but not edit	Rare
RUD	View, edit, and delete	Maintain and clean up, no new rows
CRUD	Full data access	Power users, team leads
Mod	Full CRUD plus configuration	Data stewards

Attribute permissions

Attributes use two levels only: Read and Write. Leave the dropdown on *Inherit* to follow the entity.

The entity permission decides which operations are available. The attribute permission decides which fields are editable during those operations. Both must allow it.

Attribute level	Entity has R	Entity has C or U
Read	Visible, not editable	Visible, not editable
Write	Visible, not editable	Visible and editable

Examples:

Entity CRU, attribute Salary = Read — the user edits rows, but the Salary field stays locked.
Entity R, attribute Name = Write — view only. Write has no effect, because the entity grants no Update.

Moderator forces every attribute to Write

When an entity or model has Moderator, all its attributes are forced to Write ↑ and their dropdowns are disabled. Saving removes any leftover attribute overrides underneath. Remove the Moderator flag and the dropdowns become editable again.

Domain fields

A domain attribute follows the same Read and Write rules. Users do not need permission on the referenced entity to use its values in a dropdown — permission on that entity only controls whether they can browse it directly.

Multiple roles

When a user belongs to several roles, the most permissive combination wins. Read plus Create-Read-Update gives Create-Read-Update. This applies at model, entity, and attribute scope. One role can never block another.

Server-side enforcement

Every permission is checked on the server. A request that bypasses the interface is rejected with HTTP 403.

Audit trail

Each changed permission is written to the audit log as a separate entry with Action = permission_change. Saving a role can therefore produce many entries at once. The Details field records exactly what changed:

{
  "scope": "entity",
  "modelId": 3,
  "modelName": "Customer",
  "entityId": 12,
  "entityName": "Branch",
  "roleId": 2,
  "roleName": "DataSteward",
  "changes": {
    "canRead": { "from": false, "to": true },
    "canUpdate": { "from": true, "to": false }
  }
}

For attribute scope, changes holds level instead of the CRUD flags. The permission update and the audit entry succeed or fail together.