Overview
Mobaro offers two ways to give a User permissions: Super User access (unrestricted) and Roles (scoped). Picking the right one is one of the most consequential decisions you make in your Mobaro setup — it shapes your security posture, your audit story, and how easily you can onboard and offboard team members. This article walks through when to use each, with side-by-side comparisons and real-world patterns.
The bottom line: Default to Roles. Only grant Super User access when the User truly needs unrestricted control of every component on the account. Roles cover the vast majority of access needs and are far easier to evolve as your team grows.
The two access models
Super User access
A Super User can create, edit, and delete every component in the account, across every Organization they are a Super User of. Super User access is binary — it cannot be partially scoped, limited to specific Locations, or restricted to read-only. It is granted and revoked exclusively through Mobaro Support to maintain an auditable trail.
See also: What is a Mobaro super user? for a fuller walkthrough of Super User capabilities and responsibilities.
Roles
A Role is a named bundle of granular permissions that you create and assign in the Mobaro Backend. Roles can grant View, Modify, Create, Delete or Administrate permissions on specific feature areas (Checklists, Assignments, Dashboards, Schedules, Users, Locations, etc.). A User can hold multiple Roles, and Roles can be combined with Location and User Group memberships to scope access precisely.
See also: How to set up Roles for the configuration walkthrough.
Side-by-side comparison
Capability | Super User | Role |
Account-wide access across all Organizations | Yes | No |
Scoped to specific Locations or Location Groups | No | Yes |
Read-only access option | No | Yes |
Can manage other Users and Roles | Yes | If granted |
Can be granted from the Mobaro Backend | No | Yes |
Can be revoked from the Mobaro Backend | No | Yes |
Can be combined with other Roles | N/A | Yes |
Audit trail of grant/revoke events | Limited | Limited |
Time to grant or revoke | Up to 3 business days | Immediate |
When to grant Super User access
Reserve Super User access for Users whose responsibilities genuinely span the entire account. Typical examples:
Account owner or executive sponsor — needs unrestricted oversight across all Organizations and components.
System administrator — manages Users, Roles, integrations, and global Configuration.
Mobaro program lead — owns rollout, training, and platform-wide best practices.
Backup administrator — your second Super User, in place to cover for the primary in case of leave or unavailability.
Recommendation: Maintain at least two and at most a small handful of Super Users per Organization. Two ensures resilience; more than four or five usually indicates that some of those Users could move to a permissive Role instead.
When to use a Role instead
Use a Role any time the User's job can be described in terms of which features they need and which Locations they cover. That covers nearly every operational, supervisory, and reporting role at a park. Examples:
Park manager — needs full visibility on their park's Locations and Checklists, but not on other Organizations on the account.
Maintenance supervisor — manages Assignments and Checklists for the rides they own, plus Asset records.
Operations lead — manages RideOps configuration and Schedules for a defined set of Locations.
Compliance officer — view-only across Results, Dashboards, and audit trails for reporting.
Frontline operator — completes Checklists for Locations they are a member of; no edit access to configuration.
Decision guide
Use this checklist to land on the right call. If any answer is no, a Role is almost certainly the better fit.
Question | Use Super User if… |
Does the User need to access all Organizations on the account? | Yes |
Will the User regularly create or modify Roles for other Users? | Yes |
Will the User own global Configuration (RideOps, Notification Rules, Assignment Definitions)? | Yes |
Will the User act as the primary Mobaro escalation contact for your team? | Yes |
Is the User accountable for the Mobaro account at an executive or ownership level? | Yes |
Watch out: A common anti-pattern is granting Super User access to bypass a Role that hasn't been configured yet. If you're tempted to do that, build the Role first — it's almost always faster than the Super User activation flow, and far easier to revoke later.
Common patterns
Two Super Users + scoped Roles for everyone else
The most common healthy setup. The account owner and one IT or operations lead hold Super User access. Every other team member is on a Role tailored to their job — park manager, supervisor, technician, operator, etc. New hires get a Role; departing employees get the Role removed.
Replacing Super User access with a Role
When a User no longer needs unrestricted access (for example, they move to a regional manager role from a corporate admin role), submit a Super User deactivation request and specify the replacement Role in the same request. Mobaro Support will swap the access in one step. See Deactivating a Super User for the request flow.
Emergency Super User
For accounts that operate 24/7 (cruise lines, year-round resorts), some teams maintain a third Super User account explicitly for break-glass scenarios — held by a senior on-call engineer. Use sparingly and review quarterly.
See also
What is a Mobaro super user? — foundational article on the Super User role.
Activating a new Super User — the request flow for granting Super User access.
Deactivating a Super User — the request flow for removing Super User access.
How to set up Roles — configuring scoped permission bundles.
Create new users in your organization — assigning Roles when creating a User.
Frequently asked questions
Q: Can I combine Super User access with Roles?
A: Combining isn't necessary — Super User access is unrestricted and supersedes any Role assignment. If you find yourself wanting to add Roles "on top of" Super User access, that's usually a signal you actually want a Role-based setup instead.
Q: How many Roles can a User hold at once?
A: There is no practical limit. Permissions are unioned, so a User receives the broadest permissions across all assigned Roles. Use this to compose access from smaller, reusable Role definitions.
Q: Can a Role include the ability to manage other Users?
A: Yes. The Users permission area supports View, Modify, and Administrate levels. Granting Administrate on Users gives Role-based User management without requiring Super User access.
Q: Will using Roles slow down account changes?
A: The opposite. Granting and revoking Roles is immediate from the Mobaro Backend, while Super User changes go through Mobaro Support and take up to one business day. Role-based access is faster to evolve in every scenario except the initial setup.
Q: What if I'm not sure which Role a User needs?
A: Start with the most restrictive Role that lets the User complete their day-to-day work, then add permissions as gaps appear. This is easier to audit and safer than starting broad and trying to scope back.