Overview
Most access questions in Mobaro — "why can't this person see that ride's Results?", "why can they edit every Schedule?" — come down to four building blocks: Super User, Roles, Location membership and User Groups. Each does a different job. This article explains how they fit together, so you can work out why someone can or can't see or do something.
At a glance |
|
Who can do this | Super Users. A Role with Roles or User Groups permissions can also manage those. Super User status: Mobaro only. |
Where | Users, Roles, User Groups and Locations in the Backend |
Works on | Backend (web) and Mobile app |
Availability | All organizations |
💡 Why this matters: A Role decides what someone can do. Location membership decides which Locations' Results, Assignments and Notes they see. Most "they have the Role but still can't see it" problems are a missing Location membership.
The four building blocks
Building block | What it controls |
Super User | Every permission in the organization, in every area and at every Location. Granted per organization, by Mobaro only. |
Role | What a User can do in each Backend area, such as View, Create, Modify or Delete for Checklists, Schedules or Users. A Role applies across the whole organization. |
Location membership | Which Locations a User works at. It limits the Location-based records they see, such as Results, Assignments, Notes, Gallery images and Downtime, and what the Mobaro app shows them. |
User Group | A named group of Users. Use it to assign work, make many Users members of a Location at once, and give a Role to every member. |
How the pieces combine
To decide whether a User can do something, Mobaro checks:
Is the User a Super User in this organization? Then they can do everything here, whatever their Roles. Super User status applies per organization. A Super User has every permission in each organization they're a Super User of, and no extra access in any other organization.
Otherwise, do their Roles allow it? Permissions add up across every Role the User holds, directly or through User Groups. If any of their Roles grants a permission, they have it.
Is it a Location-based record? For records at a Location, such as Results, Assignments, Notes, Gallery images and Downtime, the User must also be a member of that Location. This applies even when their Role has View permission for that area.
Configuration isn't limited by Location membership. Checklists, Schedules, Locations, Users and Roles are managed across the whole organization, so a Role with Schedules › Modify lets someone edit every Schedule, not only Schedules for their Locations. A few permissions do also need membership: Assets › Administrate works only at Locations the User is a member of, and approving a Missing Result needs Location membership and being one of the Schedule's Reviewers. Without a Role with Locations › View, membership also decides which Locations and Assets the User sees.
⚠️ Heads-up: A Role can't be limited to certain Locations. To keep someone to their own area, rely on Location membership for Results, Assignments and Notes, and only give them configuration permissions (Checklists, Schedules, Locations) that they may use everywhere.
Location membership
A User is a member of a Location when they're added to it directly, through a User Group, or through a Location Group the Location belongs to. Location membership decides:
Which Locations' Results, Assignments, Notes and Gallery images they see in the Backend.
Which Checklists the Mobaro app shows: scheduled Checklists where they or one of their User Groups is an assignee, at Locations they're a member of.
That they can open the Location itself, even without a Role with Locations › View.
A Role with Locations › View lets someone see every Location record, but it doesn't make them a member. It doesn't show them those Locations' Results or Notes. To add members, open the Location and use Direct Memberships, or add a User Group to it. Only Super Users can add Locations from the User editor or the User Group editor. See Giving Users access to a Location.
What User Groups do
A User Group on its own grants no permissions. It's a way to act on many Users at once:
Assign work: add the group as an assignee, reviewer or owner, for example on a Schedule.
Give Location membership: add the group to a Location, and every member becomes a member of that Location.
Give a Role: add the group to a Role, and every member gets that Role's permissions.
Delegate User management: a User Group's Administrators can view, edit, disable and enable its members without any Users permission.
For more, see User Groups vs Roles and Create and manage User Groups.
Example: a technician in one zone
Maria is a maintenance technician who should work on the East-zone rides only.
She holds a Maintenance Technician Role with Assignments › View and Modify. It has no Schedule or User permissions.
She's in the Maintenance — East User Group, which is a member of the East-zone Locations.
Maria sees and updates Assignments at the East-zone Locations, and the app shows the Checklists assigned to her group there. She doesn't see West-zone Assignments or Results. Move her to the West group and her Locations change, with no Role change. If her Role also had Schedules › Modify, she could edit every Schedule in the organization, East or West.
Where Super Users fit
Super User status is an override for the few people who administer the whole organization. Only Mobaro can make someone a Super User or remove Super User status. There's no option for it in the Backend. Super User status doesn't add Checklists to the Mobaro app: a Super User sees scheduled Checklists where they or one of their User Groups is an assignee, at Locations they're a member of. For when to use Super User access and when a Role is better, see Super User access vs Roles and What is a Mobaro super user?.
Best practices
Give Location membership through User Groups rather than User by User.
Build focused Roles around jobs, and remember that each Role applies across the whole organization. See Role permissions reference and Set up Roles to manage permissions.
Don't use Locations › View to give access to a Location's data. Make the User a member instead.
Keep Super User access for the few people who administer the whole organization.
Frequently asked questions
I gave the user the right Role, but they still can't see a Location's Results, Assignments or Notes. Why?
They aren't a member of that Location. Results, Assignments, Notes and Gallery images only show for Locations the User is a member of, whatever their Role. Add the User, or a User Group they're in, to the Location.
How can I limit a user to only their own area?
Make them a member of only those Locations, directly or through a User Group. That limits the Results, Assignments, Notes and app Checklists they see. Roles can't be limited to Locations, so leave out configuration permissions they shouldn't use everywhere.
Why can a user see all the results, and how do I stop that?
A Role with Results › View shows every Result at the Locations the User is a member of. Remove it from their Roles, then use each Schedule's Results visible to setting. See Viewing Checklist Results.
I'm a super user in one of our organizations but not in another. Why?
Super User status applies per organization. A Super User has every permission in each organization they're a Super User of, and no extra access in any other organization. To get it in another organization, ask Mobaro; see Activating a new Super User.
Do role permissions affect what users see in the app?
Partly. Which Checklists the app shows depends on assignments and Location membership, not on Roles. Some app features do use Role permissions: for example, handling Missed Results in the app needs Results › Validate Missing.
What can an administrator of a user group do?
View, edit, disable and enable the group's members, without needing any Users permission. Add them under Administrators in the User Group editor.
