Role Permissions Manager

Use Role Permissions Manager to review and change the actions a role can perform on a document type. This guide covers the complete process: identify the required access, review the users affected, change a permission rule, check related records, test the result, and remove access that is no longer needed.

A permission change affects every user with that role. Use an existing suitable role where possible. Create a separate role when a smaller group needs extra access.

Before you start

Confirm that you have:

the System Manager role to open and change Role Permissions Manager;
approval for the role, document types, actions, and users affected;
a record of the current rules so you can restore the previous settings;
a user who can test the result in their own session; and
a safe example for testing, with no need to submit a real invoice, payment, or stock movement.

Write the required result in business terms. For example: “The purchasing team can read Purchase Receipts and export the list, but cannot cancel receipts.” This gives you both an allowed action and an action that must remain blocked.

Do not give System Manager to a user only to remove a permission error.

1. Decide which access control to change

Need	Use
Give a user an existing set of actions for their job	Assign the suitable role on the User record.
Change the actions available to everyone with a role	Role Permissions Manager.
Limit a user to a company, warehouse, project, or other permitted records	User Permission.
Control access to selected fields	Permission levels, with the field-level permissions guide.
Control entry to a specific page or report	Review Role Permission for Page and Report, as well as the underlying document permissions.
Change the menu items a user sees	Review their module access. Hiding a menu item does not remove document access.

Roles grant access together. If one role permits an action, removing that action from another role does not remove the user's access. Review all roles assigned to the user before changing a rule.

For a single user, first check whether assigning an existing role solves the need without giving unrelated access. If it does not, create a clearly named role for the approved job function and configure only the required document types. Avoid changing a widely used role for a one-person exception.

2. Open the manager and review the current rules

Use the search bar to open Role Permissions Manager. You can also open it from the Users workspace.
Set Document Type to the record you need to review, such as Supplier or Purchase Receipt.
Set Roles to the role you need to review. Leave this filter empty when you need to compare all roles for the selected document type.
Read the Role, Level, and Permissions on each matching row.
Record the existing settings before you make a change.

Users workspace with the Role Permissions Manager link

You can select a role without a document type to review that role across multiple record types. Select both filters when you need to make a focused change.

Role Permissions Manager with Document Type and Roles filters

Select the role name in a permission row to see which users have that role. Review this list before changing a shared role. Do not assume that the user who reported the issue is the only person affected.

The example below shows the current Supplier rule for Accounts User on a demonstration site. It illustrates the controls, not a recommended permission set for every organisation.

Supplier permission rule filtered to Accounts User

3. Choose the required permissions

Use Level 0 for normal document access. A higher level controls fields assigned to that level; it does not replace access to the document itself.

Permission	What it allows
Select	Select an existing record in a link field without granting normal access to open the record.
Read	Open and view permitted records.
Write	Edit permitted existing records, subject to their status and other controls.
Create	Create new records.
Delete	Delete records when their status and links allow deletion.
Submit	Submit documents that support submission.
Cancel	Cancel submitted documents when other checks permit it.
Amend	Create an amended version of a cancelled document.
Print	Print documents or download their PDF output.
Email	Use the document's email action.
Report	Access reports for the document type, subject to any report-specific role checks.
Import	Use Data Import for the document type, subject to import support and the required create or update access.
Export	Export permitted data.
Share	Share document access with another user.

Set dependent rights in the required order: Write before Submit or Amend, Submit before Cancel, and Create before Import. When removing rights, clear the dependent action first. NexWave rejects a rule that does not meet these requirements.

Not every permission appears for every document type. Submit, Cancel, and Amend appear only for documents that support submission.

For common tasks:

To view a record, review Read.
To create and maintain master records, review Read, Create, and Write. Do not add Delete unless the job requires it.
To run a report and download its results, review Read, Report, and Export, plus any report-specific access.
To prepare a transaction without posting it, grant the required draft access and keep Submit clear for that role. Check that no other assigned role permits submission.

Keep Cancel, Amend, Delete, Import, Export, and Share limited to the approved need. A user who can view a record does not automatically need to export or share it.

Use Only If Creator carefully

Only If Creator limits the rule to documents created by the user. It does not mean “assigned to this user” or “for this employee”. Another assigned role with an unrestricted rule can still grant wider access.

Do not use it for a team that must process records created by other staff unless that restriction is intended. Report is not available on a rule limited by Only If Creator. Use the appropriate record-level controls when a user needs reporting within a permitted company or warehouse.

4. Add or change the rule

Change an existing rule

Confirm Document Type, Roles, and Level again.
Tick or clear only the permissions approved for this change.
Wait for the update to finish. If NexWave shows an error, read it before you continue.
Reload the page and confirm that the intended values remain selected.

Each checkbox change is saved immediately. There is no separate Save button for the permission table. Do not click permissions to explore what they do.

Add a rule when none exists

Select Add A New Rule.
Confirm Document Type and Role.
Set Permission Level to 0 for document access.
Select Add. This saves the rule and initially grants Read.
Review the new row and set only the remaining approved permissions.
Reload the page and confirm the saved result.

Add New Permission Rule dialogue with document type, role, and permission level

The dialogue image shows the required fields only. Use your approved role, and add a rule only if a matching rule does not already exist. Do not add a duplicate to try to override an existing rule.

If you created a separate role, assign it to the intended users on their User records and save those records. Creating a permission rule does not assign the role to anyone.

5. Check linked records and reports

A transaction can require access to related records. For example:

Creating a Supplier and maintaining its bank details involve Supplier, Bank Account, and relevant linked records. Supplier access alone does not grant Bank Account access.
A Purchase Receipt may need access to the linked Address, Item, and Warehouse records used in the workflow.
A finance page may load Project or another configured accounting dimension even when the main transaction has the correct permission.

Use the document type named in the permission error to identify the missing access. Decide whether the user only needs to select that record or whether the screen must read its details. Select does not replace Read when a page loads the related records.

For a report, check its underlying document type and any separate report roles. If a user can view a Purchase Receipt list but cannot export it, check Export on Purchase Receipt. Do not add a broader finance or stock role only to enable that export.

A permission change does not bypass a workflow approval, a closed accounting period, document validation, or a record-level restriction.

6. Test with the affected user

Ask the user to reload their session. If the old access remains, sign out and sign in again. Use the user's own session or an approved test account with the same roles and User Permissions. An Administrator session does not prove that ordinary user access is correct.

Check the complete task, not only whether a button appears:

Test	Expected result
Open the required list and an allowed record	The user can read the correct records.
Select the related records needed by the task	Required links work without unnecessary access to unrelated data.
Create or edit a safe draft, if this is required	The intended action works. Do not submit a live transaction for a permission test.
Run the required report, if this is required	The report loads with the correct permitted scope.
Try the required print or export action	The approved output is available and contains only permitted data.
Check an action that must remain blocked	Unapproved submission, cancellation, deletion, or export remains unavailable.
Check a record outside the permitted company or warehouse	Existing record restrictions still apply.

Use Permitted Documents For User to help review record visibility. Combine that result with the action tests above; a visibility report does not prove that every create, submit, or export action is correct.

Record who tested the change, the result, and the final role settings. If a linked-record error appears, return to step 5 and review that specific dependency.

7. Remove unwanted access or recover a change

When a user changes jobs, review their assigned roles and remove those they no longer need. When changing a shared role, check the effect on all users who retain it.

To undo a mistaken permission change:

Reopen the same document type and role.
Restore the checkbox values from your pre-change record.
Reload and confirm the saved settings.
Repeat the user's allowed and blocked action tests.

Use the row's bin icon only when the whole permission rule must be removed. Review its users and level first. Removing one rule may leave access through another role.

Restore Original Permissions resets the selected document type to its original permission rules. It can remove other custom rules for that document type, including rules for roles outside the current filter. It is not a one-change undo button. Review the displayed original rules and the full impact before you confirm a reset.

Final review checklist

The approved task, document types, actions, and users are recorded.
All roles assigned to the affected user were reviewed.
Shared-role changes were checked for their effect on other users.
The correct Level 0 rule and any required linked-record access are saved.
The user completed the required task in their own session.
Unapproved actions and out-of-scope records remain blocked.
The previous settings and test results are available for later review.

Troubleshooting

Problem	What to check
Role Permissions Manager will not open	Confirm that your user has System Manager. Ask an authorised administrator to make the change.
No rule appears	Check both filters. An empty result means that this document type and role have no matching rule, not that the user has no access through other roles.
A new rule already exists	Edit the existing row for the same document type, role, level, and creator restriction.
The user still has access after a permission is cleared	Check all their roles, shared documents, and other applicable access controls.
The user sees the list but cannot create a record	Check Create on the correct document type and the user's assigned role.
A linked-record permission error appears	Check the named related document type. Grant only the required Select or Read access.
A report or export is blocked	Check the report's reference document type, Report, Export, and any report-specific roles.
Only some records are visible	Review User Permissions, Only If Creator, and shared documents.
A field is missing or read-only	Review its permission level and field settings. Use the field-level permissions guide.
A submitted document cannot be edited	Check document status, workflow, and permitted post-submission fields. Write does not make every submitted field editable.
A checkbox change is rejected	Read the validation message and recheck the rule. Do not assume that an unsuccessful change was saved.