Overview
Roles decide what each User can do in Mobaro. Well-designed Roles let people do their jobs without access they don't need, and stay easy to audit as your team and your Mobaro setup grow. This article collects the practices that keep Roles tight.
To create a Role, see Set up Roles to manage permissions. For what each box allows, see the Role permissions reference. For how Roles combine with Location membership, User Groups and Super Users, see How access works in Mobaro.
At a glance |
|
Who can do this | Super Users, or a Role with Roles › Create (for Roles you create) or Roles › Modify |
Where | Administrate › Roles |
Works on | Backend (web). Role permissions also apply in the Mobile app and RideOps. |
Availability | All organizations |
🛑 Critical: Anyone who can create or edit Roles can give any permission to anyone, including themselves. Give Roles permissions only to a small, trusted group of administrators.
Build Roles around jobs
Name Roles for responsibilities, not people. Ride Inspector or Maintenance Planner stays useful when staff change; Admin – Bob doesn't.
Start with View. Add Create, Modify or Delete only when the job needs it. In most areas, Create on its own already gives View, Modify and Delete for the items that User created.
Use small Roles that combine. Permissions add up across every Role a User holds, directly or through a User Group, and a Role can't take a permission away. When one team needs one extra thing, give that team a second, focused Role instead of widening a shared one.
Give Roles to User Groups. Everyone who joins the group gets the Role, and everyone who leaves loses it.
Know what a Role can't limit
Roles apply across the whole organization. They can't be limited to certain Locations: Schedules › Modify lets someone edit every Schedule.
Location membership limits the data. Results, Assignments, Notes, Gallery images and Downtime show only for Locations the User is a member of, whatever their Role. To keep someone to their area, make them a member of only those Locations. See Giving Users access to a Location.
Locations › View isn't access to a Location's data. It shows every Location record, but doesn't make anyone a member or show them that Location's Results or Notes.
Checklists › Modify covers every Checklist. To let someone edit only some, use checklist permission folders.
Treat these permissions as high-impact
Some permissions let someone change who can do what, or remove records for good. Give them to few people and check them at every review:
Permission | Why it matters |
Roles › Create or Modify | Give any permission to anyone, including themselves. |
User Groups › Modify | Add people, including themselves, to a User Group that holds a Role or Locations. A group's Administrators can do the same for their group. |
Locations › Modify, Location Groups › Modify | Add Users, including themselves, as members of any Location or Location Group, and so to its Results and Assignments. |
Users › Modify | Change other Users' email addresses and set their passwords. |
Organization › Administrate | Open Organization › Configuration, including the API tab where API keys are managed. |
Any Delete box | Remove records. Results › Delete removes inspection history. |
Review Roles regularly
Roles drift after reorganizations, new modules and temporary requests. Review them on a fixed rhythm that suits your operation, for example every quarter and before each season, and after any big change.
Administrate › Roles lists each Role's Name, Description, Users and User Groups, so you can see who holds what.
In Administrate › Users, a User's Direct Memberships show the Roles given to them directly, and Inherited Memberships show the Roles they get through User Groups.
Use each Role's Description to record its purpose and who should hold it, so the next administrator understands it.
Best practices
Use this checklist during each review:
Role names describe job functions, not people or "misc admin".
Every Role has a Description saying what it's for and who should hold it.
Each high-impact permission above has a clear reason, and is held by as few people as possible.
Roles that do almost the same job are merged.
Temporary access has been removed.
Roles are given to User Groups rather than User by User, where you can.
Location access comes from membership, not from Locations › View.
Frequently asked questions
A user shouldn't be a super user but should see everything. Can a role with every View box do that?
Partly. View boxes show every item in those Backend areas, but Results, Assignments, Notes, Gallery images and Downtime still show only for Locations the User is a member of. Add them to those Locations as well. Only Mobaro can grant Super User status.
How do I figure out why someone has an inherited role?
Open the User in Administrate › Users. Inherited Memberships lists the Roles they get through User Groups. To take one away, remove them from that User Group, or remove the group from the Role.
Can I create a view-only user?
Mostly. Give them a Role with only View boxes. Anyone in the organization can still create Assignments. See Set up Roles to manage permissions.
Which permission does someone need to do a specific task?
Look it up in the Role permissions reference, which lists every box and what it allows. Then add it to a focused Role for that job rather than to a broad shared Role.
Do role permissions affect what users see in the app?
Partly. Which Checklists the Mobile app shows depends on assignments and Location membership, not Roles. See How access works in Mobaro.