Overview
A Role is a named set of permissions that decides what a User can do in Mobaro, area by area: for example viewing Results, editing Schedules or managing Users. You build Roles around jobs, such as Ride Inspector or Maintenance Planner, and give them to Users or to whole User Groups.
This article explains what Roles control and where their limits are. To create one, see Set up Roles to manage permissions. For every permission you can tick, see the Role permissions reference.
At a glance |
|
Who can do this | Super Users, or a Role with Roles › Create, Modify or Delete |
Where | Administrate › Roles |
Works on | Backend (web). Role permissions also apply in the Mobile app and RideOps. |
Availability | All organizations |
💡 Why this matters: A Role decides what someone can do, not where. Knowing what a Role does and doesn't cover helps you give each job the minimum it needs, and look in the right place when someone "has the Role but still can't see it".
What a Role controls
In the Role editor, each area of Mobaro has its own boxes. Most areas use the same four levels:
Permission | What it allows |
View | See the items in that area, for example every Checklist in the Backend. |
Create | Create new items. In most areas it also gives View, Modify and Delete for the items that User created. |
Modify | Edit any item in the area, not only your own. |
Delete | Delete any item in the area. |
Area-specific | Some areas have their own boxes, such as Results › Validate, Operations › Manage Downtime or Assets › Administrate. |
Not every area has all four. For example, Assignments has no Create box because anyone in the organization can create Assignments. The Role permissions reference lists each box.
How Roles behave
Permissions add up. A User gets every permission from every Role they hold, directly or through a User Group. A Role can't take a permission away.
A Role applies across the whole organization. It can't be limited to certain Locations. A Role with Schedules › Modify lets someone edit every Schedule in the organization.
Roles belong to one organization. If a User works in several Mobaro organizations, give them a Role in each one.
Changes apply straight away. When you edit or delete a Role, everyone holding it gets the new permissions.
Roles don't decide the app's Checklists. The Mobaro app shows scheduled Checklists where the User or one of their User Groups is an assignee, at Locations they're a member of. Some app features do use Role permissions: handling Missed Results in the app needs Results › Validate Missing.
What a Role doesn't do
It doesn't give Location membership. Results, Assignments, Notes, Gallery images and the Downtime page show only for Locations the User is a member of, whatever their Role. See Giving Users access to a Location.
It doesn't make someone a Super User. Only Mobaro can make someone a Super User. See What is a Mobaro super user?.
It can't cover only some Checklists. Checklists › Modify covers every Checklist. To let someone edit only some, use checklist permission folders.
For how Roles combine with Super Users, User Groups and Location membership, see How access works in Mobaro and User Groups vs Roles.
Best practices
Build Roles around responsibilities, not people: "Assignment administrator" is easier to maintain than "Admin – Bob".
Start with View and add Create, Modify or Delete only when the job needs it.
Treat Delete permissions, and the Roles and Users areas, as high-impact. Give them to a small, trusted group.
Keep a few well-designed Roles and use them the same way across departments, rather than dozens of slightly different ones.
Give Roles to User Groups where you can, so new team members get the right access when they join the group.
Review Roles regularly so access stays aligned with your team.
Frequently asked questions
If a user group has no roles, do its members have access to everything?
No. Without a Role, a User has no Role permissions. They can still complete Checklists assigned to them at their Locations and create Assignments, but they can't manage Checklists, Schedules, Users or other areas. Only Super Users have every permission.
If a role doesn't include Checklists, can users still see their checklists in the app?
Yes. The app shows scheduled Checklists where the User or one of their User Groups is an assignee, at Locations they're a member of. Checklists permissions only control the Checklists area of the Backend.
Does Checklists › View show all checklists or only the user's own?
All of them. Checklists › View shows every Checklist in the Backend. Checklists › Create alone gives View, Modify and Delete only for Checklists that User created.
Do I need to be a super user to create checklists and schedules?
No. A Role with Checklists › Create and Schedules › Create is enough. See Set up Roles to manage permissions.
How can I see which permissions I or someone else has?
Open the User in Users: Direct Memberships and Inherited Memberships list their Roles and User Groups. To see what a Role allows, open it in Administrate › Roles, which needs a Roles permission or Super User status.