Skip to main content

Mobaro Cross-team Utilization

Three worked examples of routing work between teams in Mobaro, with the trigger, delegation and Note Type settings behind each one.

Written by Logan Bowlby

Overview

Work often starts in one team and ends in another: Food & Beverage spots a fault that Facilities fixes, or a ride operator reports a spill that Custodial cleans up. Mobaro routes that work as an Assignment to the right User Group, with the Location, details and photos attached, so nobody has to pass it on by phone or radio.

This page shows three worked examples with short videos, and the settings behind each one. Each section links to the full how-to.

At a glance

Who can do this

Setup: Super Users, or Roles with Checklists › Modify (triggers), User Groups › Modify or the group's Administrators (delegable groups) or Organization › Administrate (Note Types). Raising work: any User.

Where

Checklist editor › question › Triggers; User Groups › Delegable user groups; Configuration › RideOps › Note Types

Works on

Backend (web) to set up; Mobile app and RideOps to raise work

Availability

All organizations. The RideOps example needs RideOps.

💡 Why this matters: Handoffs between departments are where issues get lost. When the team that finds a problem can route it straight to the team that owns it, the fix is tracked from the first report to the final resolution, and both teams see the same record.


How work crosses teams

Setting

Use it when

Full guide

Assignment trigger

A Checklist answer should raise work for a set team, for example a failed temperature check.

Delegable user groups

Members of one team should be able to pick another team as assignee without joining it.

Note Type with Trigger Assignment

Operators should raise work from a Note in RideOps.

Critical Schedules and dashboards

Leaders need to see whether each Location is ready to open.

Whichever route you use, the receiving User Group must have Assignments ticked under Assignability, and its members need access to the Location, or they won't be offered as assignees or see the work. See Create and manage User Groups.


Example: F&B cooler check

Example: During a routine cooler check, an F&B team member records a temperature above the limit. The Checklist raises an Assignment for the Facilities User Group, with the Location and the answer attached.

To set this up, add an Assignment Trigger to the Temperature Question with a condition such as greater than your limit, and choose Facilities in Assigned to (Users/User Groups). By default the team member sees the prefilled Assignment and confirms it; tick Require no user intervention when creating assignment to create it without stopping them. Facilities members are notified according to their notification settings. See Assignment triggers in Checklists.


Example: reporting from RideOps

Example: A ride operator notices a spill at the ride entrance. Without leaving the tablet, they report it, and the team that cleans it up gets an Assignment.

In RideOps, operators can raise work in two ways: by creating a Note whose Note Type has the Trigger Assignment action, or by answering a Checklist question that has an Assignment trigger. On the Note Type, set the assignee and priority, and optionally Require no user intervention when creating assignment. See Setting up Note Types.


Example: F&B pre-opening

Example: An F&B team member completes the daily pre-opening Checklist, raises an Assignment for anything that needs fixing, and the Location's readiness updates on the dashboard.

The same pattern works for retail, warehouses and any other Location type. Tick Is critical for operation on the pre-opening Schedule, so the Location shows as not ready until the Checklist is done; choose When overdue or When missing to delay that effect. By default, an open high-priority Assignment does too. Add a Location Overview widget to a dashboard to see every Location's readiness, Checklists and urgent Assignments. See Schedule criticality and Location operational status.


Best practices

  • Assign cross-team work to the receiving team's User Group, not one person, so it's picked up when someone is off shift.

  • Prefill the title and assignee on routine triggers, and turn on Require no user intervention when creating assignment so staff aren't stopped mid-check.

  • Open delegation routes only where teams really hand work to each other, and set them on a small leads or dispatcher group.

  • Name Assignments so the receiving team can act on them without opening the Checklist, for example Cooler 3 above limit – Main Street Café.


Frequently asked questions

Do you have to be in a user group to assign an assignment to it?

In the Mobile app, yes, unless one of your groups has that group as a delegable user group. In the Backend, Super Users and Roles with User Groups › View can pick any assignable group. See Delegable User Groups.

A user group isn't showing in the assignee list. Why?

The group needs Assignments ticked under Assignability and a member with access to the Location. Without User Groups › View, you only see your own, delegable and administered groups. An Assignment Definition can also limit who can be assigned. See Create and manage User Groups.

How do I stop another department from using a checklist at a shared location?

Choose that team's User Groups as the Schedule's assignees: only assignees with access to the Location get the Checklist in the app. Checklist permission folders control who can view and edit it in the Backend. See How to schedule a Checklist.

Why is Mobaro useful for F&B departments?

F&B Locations work like any other: pre-opening and temperature Checklists, Assignments to Facilities when something fails, and readiness on the same dashboards as rides. The examples on this page show all three.

Did this answer your question?