Overview
Roles are one of the most important security controls in Mobaro. Well-designed Roles let Users do their jobs efficiently without granting unnecessary access to sensitive data or Configuration. The goal is simple: give each User only the permissions they need and no more, while keeping your Role setup easy to understand and maintain. For the full menu of what you can grant, see the Role permissions reference; for how Roles fit alongside Location access and User Groups, see How access works in Mobaro.
Why this matters: Roles drift over time, and over-permissioning accumulates quietly until an audit — or an incident — surfaces it. A small set of clear, least-privilege Roles is far easier to reason about and far safer than a sprawl of one-off grants.
Best practices for Role management
Minimize permissions (least privilege)
Start every Role with the minimum permissions required for that job function, then expand only when there's a clear need.
Best practice: Build Roles around responsibilities — Operations Supervisor, Maintenance Planner — not around individuals.
Note: If a User says they "can't find something", don't automatically broaden their Role. First confirm what they're trying to access, where they expect to find it, and which Locations it applies to — the issue is often Location access, not the Role.
Be cautious with broad Location visibility
Some permissions can unintentionally grant wide access across your account.
Heads up: Avoid granting View Locations and View Location Groups unless genuinely necessary. These can expand what a User sees far beyond their intended scope.
If a User only needs specific Locations, grant that scope the recommended way — through User Group membership that carries those Locations — rather than global visibility permissions. See User Groups vs Roles.
Audit Roles regularly
Permissions drift over time — especially after organizational changes, new modules, or temporary access needs. Set a routine review schedule: quarterly as a minimum for most teams, monthly for large or multi-site operations, and after any major change such as a module rollout, season start, or restructuring.
When auditing, check:
Are there Roles with "temporary" permissions that never got removed?
Are multiple Roles doing the same job with slightly different access?
Are there Roles with high-impact permissions and no clear reason?
Document custom Roles
If you can't quickly explain what a Role is for, it will get misused over time. For each custom Role, capture the name (clear, job-function based), the purpose in a sentence or two, who should have it, the key permissions granted (especially high-impact ones), and the last reviewed date and owner.
Best practice: Keep Role documentation where your admins already work — an internal wiki, an SOP doc, or an "Admin notes" hub. Consistency matters more than the tool.
Role audit checklist
Use this during reviews to keep things tight and consistent:
Role names reflect job functions, not people or "misc admin".
Each Role has a written purpose and intended audience.
High-impact permissions are justified and intentional.
Duplicate or overlapping Roles are consolidated.
Temporary access has an expiration plan, or is removed.
New modules and features haven't introduced accidental access gaps or overreach.
Frequently asked questions
Q: What's the most common Role mistake?
A: Granting broad permissions "just to fix access quickly", then never rolling them back. Start minimal, validate the need, then expand intentionally.
Q: When should I use View Locations or View Location Groups?
A: Only when a User truly needs broad visibility across many Locations and it aligns with your governance model. Treat these as high-impact permissions, and prefer User Group membership for normal Location scoping.
Q: How many Roles should we have?
A: Fewer is usually better. Aim for a small set of standardized Roles covering your core job functions, then add specialized Roles only when needed.
Q: What if a User needs "just one extra thing"?
A: Avoid customizing a Role for one person. Reassess whether your existing Role set needs a new standardized Role, or whether the access belongs to a User Group instead.