Create and maintain roles
A role groups permissions for a job. Users can hold multiple roles; review their combined effect. Naming a role “Manager” does not grant approvals, posting or administrator powers.
Plan the role
Write the actual tasks first. For example, North Accounts Clerk may need receipt discovery, entry, posting and allocation plus customer/invoice lookups. Determine the current exact permission codes from the relevant module's access guide and the permission catalogue. Decide separately whether the role should post or only prepare records.
| Dialog field | Rule | Example |
|---|---|---|
| Name | Required, up to 100 characters in the current form | North Accounts Clerk |
| Description | Up to 255 characters | Customer receipt work; branch access assigned separately |
The browser form has no editable permission-code field. Role permissions are assigned after the role is created. ADMIN/SUPER_ADMIN are reserved/protected roles; do not create ordinary roles using their reserved identities.
Create and verify
- Open Authorization → Roles.
- Choose the available add action.
- Enter the job-based Name and a clear Description.
- Choose Create and find the role in the register.
- Open Assign permissions, locate that role and configure its complete permission set.
- Inspect the saved role before assigning it to staff.
Change an existing role
Use the role's permitted edit action for its name/description. A protected role may permit description/grant changes while forbidding rename. Follow the disabled-name message; do not attempt to bypass it through another screen.
Before changing permissions, identify everyone holding that role. Removing posting from a shared Accounts role affects all its members, including people at other branches. A role is not branch scope: apply unit access per user.
Example: split preparation from posting
Omar should prepare sales work while Nadia reviews it. Create two narrowly defined roles and assign the actual permissions for each task. This is an access design recommendation; the role screen does not create an approval workflow or enforce two-person review for every module. Each module's own transitions determine what the application enforces.
Delete only an ordinary role that the server permits you to delete. Check user assignments first and preserve a record of the approved access change. If deletion is refused, inspect protection and dependencies instead of renaming a protected role to make it removable.