Set Field-Level Permissions with Permission Levels

Use field-level permissions when a field should be visible or editable only for selected roles. This is useful for sensitive rates, costs, margins, approvals, or management-only notes on a form that other users still need to open.

In NexWave, field-level permissions have two parts:

Set the field to a higher Permission Level.
Give the trusted role Read or Write access to that same level in Role Permissions Manager.

This guide uses Item as the example. The Valuation Rate field is moved to Level 2. A user with Stock User access can still open the Item but cannot see Valuation Rate. A user with Item Manager access can see and edit it because Item Manager has Read and Write at Level 2.

Before you start

You need:

System administration access.
Permission to customise forms.
Permission to manage role permissions.
A clear decision about which roles should see or edit the protected field.

Test the change with real user roles before applying it to a live environment.

How permission levels work

Level 0 is the normal document-level permission. A role normally needs Level 0 access before higher levels matter.

Higher levels are field-level groups. A field at Level 2 is only available to roles that have access to Level 2 for that document type.

Permission levels are not a hierarchy. Level 2 does not automatically include Level 1, and Level 1 does not automatically include Level 2.

Permissions are additive. If a user has several roles, any role with the matching permission level can grant access to the protected field.

Step 1: Set the field's permission level

Open the form customisation tool, select Item, and find Valuation Rate in the field list.

Set Permission Level to 2, then save or update the form customisation.

The saved field setting below shows Item with Valuation Rate moved to Level 2. You normally make this change from the form customisation tool; the screenshot shows the saved field property so the Level 2 setting is clear.

Step 2: Give the trusted role access to the same level

Open Role Permissions Manager.

Select Item as the document type and Item Manager as the role.

Keep the Level 0 row for normal Item access. Add or update a Level 2 row for Item Manager and tick:

Read, if the role should see the protected field.
Write, if the role should edit the protected field.

In this example, Item Manager has Read and Write at Level 2.

Do not add a Level 2 row for roles that should not see the field. For example, if Sales User shouldn’t see that field at all, don’t add that row. If Sales User want to only read and no write to fields with level 2. We can add the following row to that role. Note the “Write” checkbox is not checked.

Step 3: Test with a role that should not see the field

Open the same Item as a user who has normal Item access but no Level 2 access.

In this example, the user can open the Item, but Valuation Rate is not shown.

Item form without Valuation Rate for a role without Level 2 access

Step 4: Test with the trusted role

Open the same Item as a user with the trusted role.

In this example, Item Manager can see and edit Valuation Rate because the role has Read and Write at Level 2.

Item form with Valuation Rate visible for Item Manager

Read-only setup

If a role should see the field but not change it, tick Read at the higher level and leave Write unticked.

For example:

Role	Level	Read	Write	Result
Item Manager	2	Ticked	Unticked	The field is visible but not editable
Item Manager	2	Ticked	Ticked	The field is visible and editable
Stock User	No Level 2 row	Not applicable	Not applicable	The field is hidden

Important notes

Field-level permissions protect standard form loads and standard document reads.
Standard lists, grids, and print layouts also respect field-level read access.
Custom reports, custom print formats, integrations, and scripts should be checked separately. They must not expose protected values outside the standard permission checks.
Administrator and system-level users may still have broader access.
Keep the number of permission levels low. Too many levels make access rules harder to audit.
After changing permissions, ask users to refresh the page or sign in again before testing.

Troubleshooting

Problem	What to check
A user can still see the field	Check all roles assigned to the user. Another role may have access to the same permission level.
A user cannot open the document	Check the role still has Level 0 Read access for the document type.
A user can see the field but cannot edit it	Check whether Write is ticked at the field's permission level.
The field still appears in a report or custom output	Review the report, print format, or integration separately. Custom logic may need its own permission check.