At a glance
Follow the “least permission needed” rule for every role.
Treat location visibility permissions as high-impact access.
Audit roles regularly and document custom roles so changes stay intentional.
Who this is for
Admins / super users managing roles and permissions
System owners responsible for governance and account security
Team leads who need consistent access across locations and departments
Overview
Roles are one of the most important security controls in Mobaro. Well-designed roles ensure users can do their jobs efficiently without granting unnecessary access to sensitive data or configuration tools.
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.
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.
Recommendation: Build roles around responsibilities (for example: “Operations supervisor” or “Maintenance planner”), not 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 location(s) it applies to.
Be cautious with broad location visibility
Some permissions can unintentionally grant wide access across your account.
Warning: Avoid giving View locations and View location groups unless absolutely necessary. These permissions can expand what a user can see far beyond their intended scope.
Practical rule of thumb:
If someone only needs access to specific locations, prefer targeted access methods (like assigning access through the appropriate structure) rather than global visibility permissions.
Audit roles regularly
Permissions drift over time—especially after organizational changes, new modules, or temporary access needs.
Set a routine review schedule:
Monthly (recommended for large or multi-site operations)
Quarterly (recommended minimum for most teams)
After major changes (new module rollout, season start, 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 that include high-impact permissions without a 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:
Role name (clear job-function naming)
Purpose (1–2 sentences)
Who should have it (teams / job titles)
Key permissions granted (especially high-impact ones)
Last reviewed date and owner
Tip: Keep role documentation in the same place your admins already live (internal wiki, SOP doc, or an “Admin notes” hub). Consistency matters more than the tool.
Role audit checklist
Use this checklist 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 / overlapping roles are consolidated
Temporary access has an expiration plan (or is removed)
New modules/features did not introduce 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.
Q: How many roles should we have?
A: Fewer is usually better. Aim for a small set of standardized roles that cover your core job functions, then add specialized roles only when needed.
Q: What should I do if a user needs access to “just one extra thing”?
A: Avoid customizing a role for one person. Instead, reassess whether your existing role set needs a new standardized role or whether access can be granted through a better-structured approach.