Skip to main content

Managing permissions for checklists, schedules, and data

Learn how to grant access to checklists, schedules, and reporting data in Mobaro using role permissions—so users can do their work without compromising system integrity.

Logan Bowlby avatar
Written by Logan Bowlby
Updated over 2 weeks ago

At a glance

  • Permissions control who can view, create, modify, or delete key resources in Mobaro.

  • Start with view access by default, then expand only when necessary.

  • Review roles regularly to prevent “permission creep” over time.


Who this is for

  • Admins / super users responsible for roles and account governance

  • Managers who need the right people to edit operational content

  • Teams who need access to results and reporting without full admin control


Overview

Checklists, schedules, and other resources in Mobaro are central to daily operations. By assigning permissions to these elements, you control who can interact with them and at what level.

Most permissions follow a consistent pattern across Mobaro:

  • View: See and access the item

  • Create: Make new items

  • Modify: Edit existing items

  • Delete: Remove items

Recommendation: Treat delete permissions as high-impact access and reserve them for trusted admins whenever possible.


What permissions apply to

Checklists

Checklist permissions help you control who can manage and monitor operational work.
Common permission levels include:

  • View all checklists (for completing or reviewing)

  • Create / modify checklists (for people building workflows)

  • Delete checklists (rare—reserve for admins)

Schedules

Schedule permissions help ensure only the right people can manage timing, tasks, and availability.
Common permission levels include:

  • View all schedules (for seeing what’s due)

  • Create / modify schedules (for planners and managers)

  • Delete schedules (high impact—use carefully)

Data (results, gallery, and reporting)

Controlling access to operational data is critical for:

  • Protecting sensitive information

  • Preventing accidental removals or edits

  • Ensuring reporting access matches responsibilities

Common permission levels include:

  • View results and reporting (most users who analyze performance)

  • Modify / delete data (restrict heavily; use only when required)


Best practices for managing permissions

Assign view access by default

As a best practice, start by giving users view access to what they need (like checklists, schedules, and data). Only grant modify or delete access when absolutely necessary.

Tip: If someone can’t find something, first verify whether it’s a visibility/access issue vs. a navigation/workflow issue before expanding permissions.

Create custom roles for specific use cases

If you have unique job functions (for example: managers who need to modify checklists but shouldn’t access broader configuration), create a custom role with exactly the permissions required—nothing extra.

Recommendation: Name roles by function, not by person (for example: “Checklist manager” instead of “Bob’s permissions”).

Regularly review roles and permissions

As teams grow or responsibilities change, roles drift. Make role reviews part of your normal governance process.

A good review cadence:

  • Quarterly for most accounts

  • Monthly for large or multi-site operations

  • After major changes (new module rollout, org restructuring, seasonal ramp-up)

Warning: “Temporary access” is the #1 cause of over-permissioning. If you grant elevated access to solve a short-term problem, set a reminder to roll it back.


Frequently asked questions

Q: Should everyone have create/modify access to checklists and schedules?
A: Typically no. Most teams work best when most users have view access, while a smaller group maintains the content.

Q: What’s the safest default permission set?
A: Start with view access for what users need to do their daily work, then add create/modify only when there’s a clear operational need.

Q: Why restrict access to results or reporting data?
A: Data access can expose sensitive information and can impact reporting integrity—especially if users can modify or delete historical data.

Did this answer your question?