Overview
Mobaro gives you two complementary primitives for managing access: Roles and User Groups. Customers regularly ask which one to use, when in fact most healthy setups use both — they answer different questions about a User. This article walks through the distinction, when each fits, and how they combine in practice.
The bottom line: Roles answer what a User can do. User Groups answer where they work, with whom, and on whose behalf. Most Users hold at least one of each.
The two access primitives
Roles — what you can do
A Role is a named bundle of permissions. Each Role grants View, Modify, Create, Delete, or Administrate access to specific features in Mobaro — Checklists, Assignments, Schedules, Dashboards, Users, Locations, and so on. Roles are how you control whether a User can edit a Schedule, create a Dashboard, manage Users, or just complete the Checklists assigned to them.
See also: How to set up Roles for the configuration walkthrough.
User Groups — where you work and with whom
A User Group is a named collection of Users. Groups bundle members for assignment, scheduling, notification routing, and Location access. They are how you target a team — every Lifeguard at the wave pool, every Maintenance Lead in the East zone, every member of the F&B leadership — without listing individuals each time.
See also: Create and manage User Groups for the configuration walkthrough.
Side-by-side comparison
Question | Roles | User Groups |
Controls what a User is allowed to do | Yes | No |
Controls who can be assigned work as a team | No | Yes |
Used for Notification Rule recipients | No | Yes |
Grants permissions (View, Modify, Create, Delete, Administrate) | Yes | No, unless a User Group is listed on a role. |
Bundles Users for batch assignment | No | Yes |
Grants Location membership to Users | No, unless View Locations or View Locations Groups is enabled (not recommended) | Yes |
Can be combined with others on one User | Yes | Yes |
Has its own Administrators | No | Yes |
Supports cross-team delegation | No | Yes (via delegable User Groups) |
When to reach for a Role
Use Roles when the question you are answering is about permissions — what features the User can use and at what level. Common Role-shaped needs:
A new Park Manager needs Modify access to Schedules and Assignments across their park.
A Compliance Officer needs View-only access to Results and Dashboards for reporting.
A Maintenance Supervisor needs Administrate access to Asset records.
Best practice: Build a small, reusable set of Roles ("Operator", "Lead", "Manager", "Compliance Read-Only", etc.) and reuse them. Resist the urge to create a unique Role per person — that path leads to dozens of near-identical Roles that are painful to audit.
When to reach for a User Group
Use User Groups when the question you are answering is about who does the work or receives the message. Common Group-shaped needs:
An Assignment for a broken queue gate needs to go to "everyone on Maintenance — North Zone" without listing individuals.
A Notification Rule for downtime should ping "all Park Directors" plus "the Operations Lead group".
A Schedule needs to rotate through every active Ride Operator in a region.
Adding a new Location should automatically grant access to "the F&B team" without editing each Location's User list.
Best practice: Mirror your real org chart in your Group structure. If your park has zones, regions, or departments in the real world, make those Groups in Mobaro. The closer your Group structure matches reality, the easier every other configuration becomes.
When to use both together
Most Users will hold at least one Role and belong to at least one User Group. The two compose:
A User in the Operations Leads User Group with the Park Manager Role can edit Schedules across the parks they cover.
A User in the Maintenance — East User Group with the Operator Role receives Assignments routed to the East team but cannot edit anyone's permissions.
A User in the Compliance User Group with the Read-Only Role can be targeted by Notification Rules for audit-related events but cannot modify any record.
Note: Roles and User Groups also work together for Location scoping. A Role can grant Modify on Schedules, and a User Group's Location memberships determine which specific Schedules the User can actually modify.
Common patterns
Role per access level, Group per team
The most common healthy structure. A handful of Roles cover access tiers — Operator, Lead, Manager, Compliance Read-Only, Admin. User Groups cover real teams and zones — Maintenance — North, Maintenance — South, F&B Leadership, Park Directors, etc. A new hire gets one Role and one or two Groups, and they're set up.
Function-based Groups for cross-team workflows
When work routinely crosses teams (Operations escalating to Maintenance, Maintenance escalating to specialists), use User Groups for each function and configure delegable User Groups to allow handoffs without expanding membership. The receiving team retains its own management; the originating team just gains the ability to assign work to them.
Location access through Groups, not individuals
Add Users to Locations by way of a User Group rather than directly. When the Location's coverage area changes (a new ride opens, a section closes), one edit to the Group propagates to every member — instead of editing each User one at a time.
Anti-patterns to avoid
Watch out for these structures, which create maintenance pain over time:
One Role per person — leads to dozens of near-identical Roles that are tedious to audit. Build reusable Roles instead.
Single mega-Group containing every User — defeats the purpose of Groups. Split by function, location, or zone so assignments and notifications can be targeted.
Permissions duplicated across Groups — User Groups don't grant permissions, so anything you put in a Group "for permissions" reasons should actually be a Role.
Every Group delegable to every other Group — clutters assignment dropdowns and defeats the targeting benefit. Add delegable links only where there's a real cross-team workflow.
Locations added directly to Users instead of through Groups — works initially, but becomes painful to maintain when team coverage changes.
Quick decision guide
When configuring access for a User, ask in this order:
What does this User need to do in Mobaro? → choose or create a Role.
Which team(s) do they belong to? → assign one or more User Groups.
Which Locations do they cover? → ideally inherited from the User Group; only add directly if the User has unusual scope.
Do they need to assign work to teams they're not in? → configure delegable User Groups on their primary Group.
Do they need account-wide unrestricted access? → consider Super User instead. See Super User access vs Roles.
See also
How to set up Roles — configuring permission bundles.
Create and manage User Groups — configuring User Groups and memberships.
Super User access vs Roles: choosing the right access model — for the third access tier above Roles.
Create new users in your organization — for assigning Roles and Groups when creating Users.
Frequently asked questions
Q: Can a User Group grant permissions like a Role does?
A: Yes, but only if the User Group is listed as a member of a Role.
Q: Can a Role bundle Users like a Group does?
A: No. Roles attach to Users one at a time and grant permissions. They cannot be referenced as an assignee or notification target. Use User Groups for that.
Q: How many Roles and Groups should a typical User have?
A: Most Users have one Role (matching their access tier) and one to three User Groups (matching their team and any cross-team work). Outliers in either direction are fine, but they're worth a quick sanity check.
Q: When is a Super User the right answer instead?
A: When the User needs unrestricted access across all Organizations on the account, with no exceptions. Even one of the criteria not applying means a Role is the better fit. See Super User access vs Roles.
Q: If I add a User to a User Group with a Location attached, do they get access to that Location?
A: Yes. Location membership flows through Group membership. This is the recommended way to manage Location access at scale.
Q: Can a User have a Role from one team and a User Group from another?
A: Absolutely — and it's common. Roles and User Groups are independent dimensions. A Maintenance Lead Role with a Maintenance — East User Group is a typical pairing; the Role grants edit permissions, the Group scopes who they work with and where.