Overview
The App Settings tab in Configuration controls how the Mobaro Mobile App behaves for everyone in your organization — user prompts, local saving, resumable Checklists, and confirmation modals. The same tab also holds App Area Availability Rules, which let you hide specific app areas (Checklists, Reports, Gallery, etc.) from chosen User Groups. This article covers both, and the one behavior that trips people up: how rules combine when a user belongs to more than one group.
Users must be Super Users or have the following Role to manage App Settings:
Organization: Administrate
Why this matters: App Settings is where you enforce data-handling and accountability rules across every device in the field. App Area Availability Rules let you simplify the app for frontline staff — an operator who only runs Checklists doesn't need to see Reports or Assignments — without changing anyone's underlying permissions.
Accessing App Settings
1. Open Configuration
In the Mobaro Backend, navigate to Configuration.
2. Open the App Settings tab
From the top navigation bar, select the App Settings tab. The page is split into two panels: App Settings on the left and App Area Availability Rules on the right.
App Settings
Each option changes how the Mobile App behaves for all users in the organization. Configure them to match your data-handling and accountability needs.
Setting | What it does and when to use it |
Show current user prompts in the app | Prompts the app user after a set time ( |
Disable saving locally | Prevents saving Checklist progress to the device — users must complete the Checklist or save progress to the cloud. Use when data must not persist on shared or loaned hardware. |
Disable "allow others to resume" | Removes the option for another user to resume someone else's in-progress Checklist. Use to improve accountability — only the original user can finish what they started. |
Disable starting new when resumable exists | Prevents starting a fresh Checklist from scratch when a resumable result already exists. Use to push staff to finish pending work before opening new tasks. |
Disable confirmation modal when changing answers | Turns off the confirmation modal that normally appears when a potentially unintentional answer change is detected. Leave this off (modal enabled) for safety-critical Checklists where an accidental answer change matters; enable it only where the extra tap slows down a high-volume, low-risk workflow. |
Note: When Show current user prompts in the app is enabled, the Hours and Minutes fields are required and define how long before the prompt appears (e.g., 4 hours, 0 minutes).
Critical: These settings apply organization-wide and take effect for every Mobile App user. They cannot be scoped to specific User Groups. To vary what users see by group, use App Area Availability Rules below.
Saving App Settings
Click the Save icon at the top-right of the App Settings panel to apply changes. App Settings and App Area Availability Rules are saved independently — each panel has its own save action.
App Area Availability Rules
App Area Availability Rules hide specific areas of the Mobile App from chosen User Groups. This simplifies the app for staff who don't need every area, without altering their actual permissions — a hidden area is removed from the app's navigation for affected users, not revoked at the permission level.
The areas that can be disabled per rule include: Library, Checklists, Operations, Calendar, Location overview, Reports, Assignments, Support, Gallery, and Certifications.
1. Add a rule
In the App Area Availability Rules panel, click the + button to open the Area availability rule details dialog.
2. Name the rule
Enter a clear Name that describes the rule's intent (e.g., Operators — Checklists only). Required.
3. Scope it to User Groups
Use Add group to limit the rule to specific User Groups. Leave this empty to apply the rule to all users.
4. Disable the areas to hide
In the Area name / Disabled list, toggle Disabled on for each area that should be hidden from the affected users. Areas left untoggled remain visible. At least one area must be disabled, or the rule has no effect.
5. Save the rule
Close the dialog and click the Save icon at the top-right of the App Area Availability Rules panel to apply. The rule takes effect immediately for the selected User Groups, or for all users if no groups were specified.
Best practice: Name rules by the audience and intent, not the areas (Operators — Checklists only, not Disable Reports + Gallery). When you revisit the list months later, the audience is what you'll be reasoning about, and the disabled areas are one click away.
Editing and deleting rules
Existing rules are managed from the same App Area Availability Rules panel under Configuration > App Settings.
Editing a rule
Locate the rule in the App Area Availability Rules list, click the Edit icon next to it, adjust the name, User Groups, or disabled areas as needed, then save the panel. Changes apply on the next sync for affected users.
Deleting a rule
Locate the rule in the list, click the Trash icon next to it, and confirm in the pop-up dialog.
Critical: Deleting a rule immediately restores access to all areas it previously hid, for every affected user. There is no way to temporarily suspend a rule — to pause its effect without losing the configuration, edit it (e.g., clear its disabled areas or narrow its User Groups) rather than deleting it.
How rules combine for users in multiple groups
A user can belong to more than one User Group, and more than one rule can therefore apply to them at once. When that happens, Mobaro applies the most restrictive outcome.
Critical: Disabling an area always wins. If any rule that applies to a user disables an area, that area is hidden for that user — even if another rule that also applies to them leaves the same area enabled. There is no rule that can "re-enable" an area that a different applicable rule has disabled.
Practically, the effective set of hidden areas for a user is the union of every disabled area across every rule that applies to them (including any unscoped rule that applies to all users). Plan rules additively: assume disables stack and that the most restrictive combination is what the user will experience.
Example: simplifying the app for ride operators
Scenario
Ride operators only need Checklists and Operations on their tablets. Their managers, however, also need Reports and Assignments. Some senior operators are in both the Operators and Shift Leads User Groups.
Setup
Create a rule named Operators — simplified app, scoped to the Operators User Group, with Reports, Assignments, Gallery, and Library disabled.
Create a rule named Shift Leads — full toolset, scoped to the Shift Leads User Group, with nothing disabled.
Result
A pure operator (only in Operators) sees a simplified app — no Reports, Assignments, Gallery, or Library.
A pure shift lead (only in Shift Leads) sees the full app.
A senior operator in both groups still has Reports, Assignments, Gallery, and Library hidden — because the Operators rule disables them and the most restrictive outcome wins. The Shift Leads rule leaving them enabled does not override the disable. To give this person the full toolset, remove them from the Operators group or stop disabling those areas in the Operators rule.
Saving changes
Each panel saves independently. After configuring, click the Save icon at the top-right of the relevant panel — App Settings and App Area Availability Rules are saved separately. Changes apply to the Mobile App the next time affected users sync.
Best practice: Review these settings periodically against current operational needs, test changes with a single User Group before a wide rollout, and keep a record of which areas are disabled for which groups so the multi-group interactions stay predictable.
Frequently asked questions
Q: Can I apply different App Settings to specific User Groups?
A: No. The App Settings checkboxes (user prompts, local saving, resume behavior, confirmation modal) apply universally to all Mobile App users. To vary what users see by group, use App Area Availability Rules instead.
Q: A user is in two groups with different rules. What do they see?
A: The most restrictive outcome. An area is hidden if any applicable rule disables it, regardless of what other applicable rules say. The effective hidden set is the union of all disabled areas across every rule that applies to the user.
Q: Does disabling an area remove the user's permission to it?
A: No. App Area Availability Rules only hide the area from the Mobile App's navigation for affected users. The user's underlying Role and permissions are unchanged — re-enabling the area (or removing the rule) restores access without any permission edits.
Q: Can I temporarily disable a rule without deleting it?
A: There's no pause toggle. To suspend a rule's effect without losing its configuration, edit it — clear its disabled areas or narrow its User Groups — rather than deleting it. Deleting immediately restores access to every area it hid.
Q: Can I apply a rule to an individual user?
A: No. Rules are scoped to User Groups, or applied to all users if no groups are selected. To target one person, place them in a User Group that the rule applies to.
Q: What happens if I leave the User Groups field empty on a rule?
A: The rule applies to all users. Combined with the most-restrictive behavior, an unscoped rule that disables an area hides it for everyone, including users targeted by other, narrower rules.
Q: What does "Disable confirmation modal when changing answers" actually turn off?
A: It removes the confirmation prompt that normally appears when the app detects a potentially unintentional answer change. With it enabled, answer changes are applied without the extra confirmation step.
Q: Can I customize the time interval for "Show current user prompts in the app"?
A: Yes. When the setting is enabled, set the interval in the Hours and Minutes fields (e.g., 4 hours, 0 minutes).
Q: Are these settings reversible?
A: Yes. Every App Setting and every App Area Availability Rule can be toggled or edited at any time. Re-save the relevant panel and the change applies on the next sync.