At a glance
Roles define what users can view, create, modify, and delete in Mobaro.
Use roles to reduce accidental changes and protect sensitive information.
Build roles around job functions (for example: operators vs. managers vs. admins).
Who this is for
Admins / super users defining access rules for teams
Managers who need users to access only what they need
IT / system owners focused on security and governance
Overview
Roles in Mobaro allow administrators to define specific permissions for users, ensuring they only have access to the features and data they need to perform their tasks.
Roles help you control who can:
View information
Create new items
Modify existing items
Delete items
This supports stronger security and data integrity across your organization.
Why use roles?
Roles help prevent unauthorized access to sensitive information, reduce the risk of accidental changes, and ensure users have the exact level of access they need.
Instead of giving broad access to everyone, roles let you restrict access based on job function—for example:
Operators who only need to complete daily work
Supervisors who review and follow up
Administrators who configure and manage the system
Key permissions in Mobaro
Mobaro permissions generally fall into four levels. You’ll see these patterns across many areas of the platform.
View: Allows users to see data and resources (for example: checklists, schedules)
Create: Allows users to create new items (for example: new checklists or users)
Modify: Allows users to make changes to existing resources
Delete: Allows users to remove data or resources
Recommendation: Treat delete permissions as high-impact access and reserve them for trusted administrators whenever possible.
Best practices for role design
Use these guidelines to keep roles easy to manage long-term:
Build roles around responsibilities, not individuals
Example: “Assignment administrator” is easier to maintain than “Admin – Bob”.
Keep roles consistent across departments
If multiple teams do similar work, standardize permissions so reporting and governance are predictable.
Start minimal, then expand
Give the smallest set of permissions needed for someone to succeed, then add access as required.
Avoid role sprawl
A few well-designed roles are usually better than dozens of slightly different ones.