Overview
Based on a membership is one of the six logic conditions you can add to a Checklist page or element. It shows or hides the page or element depending on which User Groups the person completing the Checklist belongs to, so one Checklist can adapt to who is running it.
This article is the reference for the membership condition. For logic in general, see Adding logic to a Checklist.
At a glance |
|
Who can do this | Super Users, a Role with Checklists › Modify (or Create, for Checklists you created), or an Administrator or Editor of the Checklist's permission folder |
Where | Checklists › a Checklist › Edit › a page header or element › Logic |
Works on | Backend (web) to set up. The logic runs in the Mobile app and RideOps. |
Availability | All organizations |
💡 Why this matters: A shared Checklist often has steps that only one team should see or do, such as a maintenance-only verification or a manager-only sign-off. Membership logic shows those steps only to members of the right User Group, so everyone runs the same Checklist but sees only the parts that apply to them.
Add a membership condition
1. Open the logic panel
Go to Checklists, select the Checklist and click Edit. Click the page header or the element you want to control, and expand Logic.
2. Add the condition
Click Add Logic and choose Based on a membership. Under Membership, choose User Group, the only option.
3. Choose the operator and User Groups
Pick one of the four operators below, then select one or more User Groups. Both are required before you can save.
4. Save
Click Accept Changes, then Save the Checklist.
Choose an operator
Operator | The page or element shows when the User is |
contains any | A member of at least one of the chosen User Groups |
contains all | A member of every chosen User Group |
does not contain any | A member of none of the chosen User Groups |
does not contain all | Not a member of at least one of the chosen User Groups |
With a single User Group, contains any and contains all give the same result, and so do the two negative operators. Use does not contain any to hide content from a group, for example to keep contractor-only steps away from staff.
Example. A handover Checklist has a page, Maintenance verification, with the condition contains any Maintenance. Operators completing the handover don't see the page; a member of the Maintenance User Group running the same Checklist does.
Whose membership counts
Mobile app — the User signed in on the device. When several people complete one Checklist, each device shows content according to its own User's groups. When a reviewer validates in the app, the reviewer's groups count.
RideOps — the Operator who signed in with their PIN. RideOps fetches their User Groups when it opens the Checklist.
Timing — the mobile app uses the User Groups in its downloaded data, so a membership change applies once the app has updated its data.
Content hidden from a User doesn't need an answer from them, so a question only one group sees is required only for members of that group. Manage who belongs to a group in Create and manage User Groups.
⚠️ Heads-up: Membership logic changes what a User sees while completing the Checklist, not who can see the answers. Anyone who can view the Result sees every answer on it. To control who can see Results or run a Checklist, use Location access, Roles and Schedules. See How access works in Mobaro.
Combine with other conditions
A page or element can have several conditions. At the top of the logic panel, choose Show this element if All conditions are met, or One or more. For example, a reviewer question with contains any Supervisors and the checklist state equal to Awaiting Validation, combined with All, appears only to a supervisor who is validating the Result.
Page logic hides everything on the page when its conditions aren't met, even elements whose own logic is met. Put each group's questions on their own page to keep them together.
Best practices
Create User Groups that match real teams, such as Maintenance or Supervisors, and use them in logic rather than building groups just for one Checklist.
Prefer contains any with one clearly named group; combinations of several groups are hard to check later.
Test the Checklist in the mobile app while signed in as a member and as a non-member before you schedule it.
Check the Checklist's logic whenever you rename, merge or delete a User Group.
Frequently asked questions
Can I restrict a question to specific users?
Not to individual Users, but to User Groups. Put those Users in a User Group, then give the question the condition Based on a membership contains any that group. Everyone else doesn't see the question and doesn't need to answer it.
Can supervisors fill in their part of the same checklist only after staff have finished?
Yes, with the checklist state rather than membership. Show the supervisor's questions only while the Result is Awaiting Validation. See Logic based on the Checklist state.
Does this stop other users from seeing the results?
No. Membership logic only hides content while the Checklist is being completed. Anyone who can view the Result sees all its answers. Result visibility depends on Location access and Roles; see How access works in Mobaro.