Roles: How to Create, Edit, and Manage Permissions in Diamond Operations Pro
The "Roles" module allows you to define what each user can see and do within Diamond Operations Pro. A role works as a permission template: it determines access to modules, available actions, and each user’s level of responsibility. For new users, this module helps answer a key security and administration question: What access does each user need to do their job without receiving unnecessary permissions?
Who should use this module?
This article is intended for:
- Owners
- Administrators
- Users responsible for configuring access
- Teams that manage internal permissions
- Supervisors or leaders who request access changes for their team
The goal is to help administrators create appropriate roles for each type of user, avoiding two common problems: granting excessive access or blocking functions needed for operations.
When should you use Roles?
Use the "Roles" module when you need to:
- Create a new type of user.
- Give different permissions to a team.
- Limit access to sensitive modules.
- Add or remove responsibilities.
- Correct access that is not working.
- Review why a user cannot see a section.
- Review why a user can see a section but cannot perform an action.
Key concepts
Before working with roles, it is important to understand these concepts:
Role
A set of permissions that defines what a user can see and do within the system.
Administrative role
A role with broad or administrative access. It should only be assigned to users who truly need to control settings, sensitive data, or critical functions.
Action permissions
Permissions related to specific actions, such as creating, editing, deleting, or viewing information.
Navigation permissions
Permissions that determine which modules or sections the user can see in the menu.
User assignment
The relationship between a user and the role assigned to them.
Understanding the roles list
The main **Roles** screen shows the roles configured in the system.
From this list, depending on the user’s permissions, you can:
- Search existing roles.
- Create new roles.
- Edit roles.
- Delete roles.
- Identify whether a role is administrative.
- Review the general permission configuration.
Before editing a role, remember that the change may affect all users assigned to that role. For example, if you modify the **Dispatcher** role, all users with that role may gain or lose access at the same time.
Before creating a role
Before creating a new role, clearly define the responsibility that this type of user will have.
Recommended questions:
- Which modules does the user need to see?
- Which actions does the user need to perform?
- Should the user create information or only view it?
- Should the user edit existing records?
- Should the user delete information?
- Does the user need access to sensitive modules such as Payroll, Roles, Transactions, or Reports?
- Will this role be used by one person or by multiple people with the same responsibility?
Creating roles based on real responsibilities helps keep the system organized and secure.
How to create a role
- Open "Roles" from the main menu.
- Select the action to create a new role. Ej: Dispatcher, Accounting, Field Supervisor, Sales, Operations Manager
- Enter a clear name for the role.
- Define whether the role will be administrative or limited.
- Configure the action permissions.
- Configure the navigation permissions.
- Save the role.
- If needed, assign the role to a test user to validate access.
How to edit an existing role
- Search for the role in the "Roles" list.
- Open the edit action.
- Review which users depend on that role.
- Adjust only the necessary permissions.
- Save the changes.
- Ask affected users to sign out and sign back in if they do not see the changes reflected.
> Important: Editing an existing role may affect several users at the same time. Before saving, confirm that the change is correct for all users assigned to that role.
How to decide which permissions to assign
Permissions should be defined according to the real responsibilities of each user or team.
Operational role
An operational user may need access to:
- Schedule
- Jobs
- Properties
- Clients
- Employees, if they assign staff
Normally, this type of user does not need access to sensitive modules such as Roles, Payrolls, or administrative settings.
Finance or accounting role
A finance role may need access to:
- Invoices
- Transactions
- Expenses
- Batches
- Financial reports
This type of role should be configured carefully, since it may handle sensitive information related to payments, billing, and financial records.
Supervisor role
A supervisor may need access to:
- Jobs
- Schedule
- Employees
- Reports
- Property information
Depending on the operation, they may also need permissions to edit jobs, review statuses, or check productivity.
Administrative role
An administrative role may have broad access to multiple modules, including sensitive settings.
Assign administrative permissions only when necessary. Not every user with operational responsibility needs full administrative access.
Limited role
A limited role can be used for users who only need to view information or perform very specific tasks.
Examples:
- Support user with read-only access.
- User who reviews jobs but cannot edit them.
- User who views reports but does not manage permissions.
- User who only needs access to part of the operational workflow.
Difference between navigation permissions and action permissions
It is important to understand the difference between being able to see a module and being able to perform actions within that module.
Navigation permissions
These permissions control whether the user can see a section in the menu.
For example, if a user cannot see "Jobs", the corresponding navigation permission is probably not enabled.
Action permissions
These permissions control what the user can do within a section.
For example, a user may be able to see "Jobs", but if they do not have edit permission, they will not be able to save changes to a job.
Both types of permissions should be reviewed when a user reports access issues.
How to test a new role? After creating a new role, it is recommended to test it before assigning it permanently.
- Create or select a test user.
- Assign the new role to that user.
- Sign in with the test account.
- Confirm that the menu only shows the necessary sections.
- Try performing the expected actions: - Create - Edit - Delete - View
- Confirm that the user does not have access to unnecessary sensitive modules.
- Adjust the role if anything is missing or excessive.
This review helps detect errors before affecting real users.
The assignment can be done from the user settings, depending on the available permissions.
- Open the user’s profile or settings.
- Find the section related to roles or permissions.
- Select the corresponding role.
- Save the changes.
- Ask the user to sign back in if the change does not appear immediately.
Common issues
A user cannot see a section
Review the role’s navigation permissions.
The user may have permissions for certain actions, but if they do not have navigation permission, they will not see the module in the menu.
A user can see the section but cannot save
Review the action permissions.
Pay special attention to whether the role has permission to:
- Create
- Edit
- Delete
- View
If the user only has view permission, they will be able to see information but not modify it.
A role change does not apply
Confirm the following:
- The role was saved correctly.
- The user has the correct role assigned.
- The user signed out and signed back in.
- There is no other role or setting limiting access.
- The change was made to the correct role.
A user has too much access
Check whether the user has an administrative role or a role with broader permissions than necessary.
Reduce permissions according to their real responsibilities and validate access again with a test account if needed.
Several users were affected by a change
This can happen when a role used by several people is modified.
Before continuing to adjust permissions, identify which users are assigned to that role and confirm the expected behavior for each group.
Best practice
- Create roles by responsibility, not by person.
- Use clear names for each role.
- Avoid granting administrative permissions unless they are truly necessary.
- Review roles after changes in the team.
- Document internally what each role is used for.
- Test new roles with a controlled account before using them broadly.
- Do not give access to sensitive modules if the user does not need them.
- Review navigation and action permissions when there are access issues.
- Before editing a role, check how many users use it.
- Keep roles simple and easy to understand.
Expected result
By the end, the administrator should be able to:
- Create clear roles aligned with real responsibilities.
- Edit permissions without unnecessarily affecting users.
- Control which modules each user can see.
- Control which actions each user can perform.
- Limit access to sensitive information.
- Resolve common permission issues.
- Maintain a secure and organized access structure within Diamond Operations Pro.