Field permissions — individual fields and individual actions
The second, finer-grained layer: access to a specific field or permission to perform one action. It works only if the role has read access to the module that owns the field.
Module permissions say “this area is allowed, that one is not”. Field permissions go one level deeper: a specific field or a specific action.
Step by step
Grant a role permission for a field or action
- Go to Team and access → Roles and permissions and click the pencil icon, Edit role.
- First, on the Module permissions tab, make sure the role has Read access to the module that owns this field. Without it, the remaining steps will have no effect.
- Go to the Field permissions tab. Above the grid you will see the heading Field-level permissions and the subtitle Control access to specific fields in modules.
- Groups appear under the name of the module that grants them — for example, under Warehouse and returns are Returns, Warehouse operations, Transfers, Picking, and Order shortages. Each group is a separate card. Click its heading to expand the field list — the arrow icon on the right changes direction. The chip next to the name shows {n} / {total} fields, the number already selected in that group.
- The Search by field or group name field above the list narrows it to matching entries and expands them automatically. A matching group shows all its fields. If nothing matches, you will see No field permissions match your search. Search only hides entries — saving the role includes all selections, including hidden ones.
- In an expanded group, select Read and/or Write for the specific entries. Toggle all in the card heading selects or clears all visible entries in the group at once (when searching, only the matches).
- Entries with a Conditional chip support conditions, but the window has no field for entering them — the chip is informational only.
- Check the counter below the grid: Configured field permissions: {n}. The No field restrictions chip means you have not selected anything.
- Click Update role, then enter the Verification code in the 2FA verification required window and click Confirm (2FA confirmation when changing permissions). Saving sends two requests — first the role, then its field permissions — so one code confirmation may cover both.
- The window closes and the role list refreshes. On failure, you will see Could not save role, and the window remains open with your selections.
If you see No field permissions instead of cards, with the message Field permissions have not been configured yet. Contact an administrator to populate the field registry., the field catalogue is empty and there is nothing to select.
The Field permissions tab disappears when you turn on Company administrator. Saving such a role does not send field permissions at all — what is in the database remains untouched and returns to the window when you turn the switch off (Company administrator and superadministrator — who bypasses what).
Enable customer data masking
Hiding personal data in roles does not work without this switch.
- Go to Settings and select the System section.
- Open the Session security tab.
- Scroll to the Data privacy heading and turn on Customer data masking (GDPR). The explanation below says: When enabled, customer data (name, email, phone, address) is masked for users without the appropriate field permissions. When disabled, everyone sees full data.
- Click Save and confirm with a 2FA code.
- Settings saved confirms success. On failure: Error saving settings.
Check the result
- Return to the User accounts tab, find someone with this role, and select Effective permissions from the three-dot menu.
- In the window, scroll to the Field permissions table — the Field and Access columns show the combined result of all the person’s roles (“Why can’t they see it?” — diagnosing permissions).
Two different uses
Data fields
Hide individual fields or block their editing — for example, a customer’s phone and email, purchase price, margin, or notes. Every field has separate Read and Write settings.
Actions
A large part of this catalogue consists of individual action permissions, not fields. Examples:
| Group | Example actions |
|---|---|
| Inventory | scanning, undoing a scan, completing, office decisions, approval, financial data |
| Receiving | starting, putting away, approval, shortage adjustment, quantity adjustment, cancellation |
| Replenishment | creating a task, bulk approval, execution, changing the target, settings |
| Warehouse operations | deleting movements, adding and removing stock, refreshing a queue |
| Returns | changing a return order (Customer service), filtering the list by all employees, forcing a closed return’s status change (“Force” in the list) |
| Reports | a separate entry for each report |
| Settings | a separate entry for each settings tab |
| Rule actions | sending tracking, sending an invoice, pushing a status |
That is why you look here for access to a specific report, not among the modules: the “Reports” module opens the area, while this tab determines which reports you can see.
The rule that saves the most time
A field permission will not work without read access to the module that owns the field.
Selecting a field in the “Orders” group does nothing for a role without read access to the Orders module. Always grant module access first, then field access.
If a field does not appear in the catalogue at all, it means “unprotected” — visible to anyone who has the relevant module.
Customer data masking has an additional switch
Hiding personal and address data works only when privacy masking is enabled in company settings. With masking disabled, everyone with module access sees full data, regardless of what you selected in the role. This is the most common cause of “I hid the customer’s phone, but it is still visible”.
Save trap: complete replacement
Saving a role deletes all its field permissions and saves them again from scratch — using only entries in the current catalogue. A permission once added manually in the database for a field outside the catalogue will disappear the next time anyone saves that role, without warning.
Conditions have no editor
Some entries support conditions, for example a permission limited to the Polish language. The window shows a hint but has no form for configuring the condition. If you need such a restriction, contact NOXTI support.
Important behaviour: a permission with a condition, checked without a specific record, is skipped — the system prefers to deny access rather than guess. If a conditional permission “does not work in the list but works in the details”, this is why.
Automation groups
Each group has a Polish name (for example Returns, Transfers, Picking); a technical name appears only for groups the window does not yet recognise. Two groups concern automation: Manual triggers and Rule actions. Both now belong to the Automations module (formerly Settings — existing grants were moved during rollout).
One exception: individual manual trigger buttons belong to the module for their area — a button on an order belongs to Orders, and one on a return belongs to Warehouse and returns. Under Automations, you will find only the aggregate entry All manual actions (all sections).
Want to see this with your orders? We’ll show you NOXTI with your sales channels and warehouse.
Book a demo