Overview
Mobaro Assets support native parent/child relationships. Every Asset can have one parent Asset and any number of children, forming a tree under each Location. The hierarchy is the primary organizing structure for Assets — there are no separate categories or grouping mechanisms.
Why this matters: A real hierarchy lets you mirror your operational structure in the data. A roller coaster has an electrical system; the electrical system has control panels; the control panels include individual MCC units. Mobaro lets you model that exactly — making large Asset libraries scannable and giving every level a place that reflects how your team thinks about the equipment.
Required access: To create, organize, or move Assets in the hierarchy, you must be a Super User or hold a Role with the Locations: Modify permission.
Critical: hierarchy does not cascade to Schedules or Assignments
Before going further, the most important behavior to understand: selecting a parent Asset as a Target on a Schedule or Assignment does NOT automatically include its children. If you target Control Panels, the Schedule applies only to Control Panels itself — not to MCC1, MCC2, OCC1, or any other child Asset under it.
Critical: To run a Checklist against every Asset in a subtree, you must target each Asset explicitly. The hierarchy is for organization, navigation, and reporting context — it is not a Schedule or Assignment selector. Misunderstanding this is the most common cause of "I scheduled it on the parent but the child Assets aren't showing the work."
How parent/child relationships work
Each Asset has three relationships that define its place in the hierarchy:
Location — the single Location the Asset belongs to. Every Asset has exactly one Location.
Parent — an optional reference to another Asset at the same Location. Top-level Assets have no parent.
Children — Assets that name this Asset as their parent. Children inherit the Location, but otherwise are independent records with their own properties, Schedules, Assignments, and history.
Two derived counts surface throughout the Mobaro Backend:
Children count — number of direct children only.
Descendants count — every Asset below in the tree (children + grandchildren + great-grandchildren, all the way down).
Note: An Asset's parent must be at the same Location as the Asset itself. The hierarchy is scoped to a Location — you cannot link Assets across different Locations into a single tree.
Where to see the hierarchy
The hierarchy surfaces in two views in the Mobaro Backend:
Tree view (on a Location's Assets tab)
When you open a Location and click into its Assets tab, you see the full nested tree. Click a node to drill in, expand a parent to see its children, and click an Asset to open its detail panel on the right. The toolbar at the top of the tree includes add, delete, and move actions for managing the structure.
List view (Locations > Assets)
The flat list view at Locations > Assets shows every Asset in the system with Name, Location, Parent, Children, and Descendants columns. Useful for auditing, sorting by hierarchy depth, finding orphan Assets, and spotting structural inconsistencies across Locations.
Setting an Asset's parent
When creating a new Asset
In the tree view, select the Asset (or Location) you want as the parent and click + on the toolbar. The new Asset is created as a child of the selected node. To create a top-level Asset (with no parent, sitting directly under the Location), select the Location itself before clicking +.
Reparenting an existing Asset
Use the move action on the tree toolbar to reparent an Asset. Select the Asset, click move, and choose the new parent from the picker. The Asset's full subtree (all of its descendants) moves with it.
Watch out: Moving an Asset to a new parent does not change which Schedules or Assignments target it. Existing Schedules continue to fire on the moved Asset directly. If your team's mental model relied on the old position in the hierarchy, audit related Schedules and reporting filters after a structural change.
Designing a hierarchy that scales
Mirror the operational structure
The most readable hierarchies match how your team already talks about the equipment. If a maintenance lead would say "the MCC1 control panel on Galaxy Coaster's electrical system," the tree should follow that exact path:
Galaxy Coaster (Location)
→ Electrical System (top-level Asset)
→ → Control Panels (child of Electrical System)
→ → → MCC1, MCC2, OCC1, etc. (children of Control Panels)
Limit depth to what's useful
There's no hard limit on how deep the hierarchy can go, but past three or four levels the tree gets unwieldy and Users start hitting "where does this thing live again" friction. Most production hierarchies stop at three levels: System → Subsystem → Component.
Make leaves the smallest tracked unit
Leaves (Assets with no children) should be the smallest physical thing you want to track individually for inspections, repairs, or reporting. Don't go finer-grained than that — every leaf comes with naming, maintenance, and audit overhead.
Best practice: Sketch the hierarchy on paper before building it in Mobaro. Get input from the people who will actually use it day-to-day — operators, maintenance, and leadership all bring different mental models, and the tree should serve all three without becoming a compromise that serves none.
A note on categorization
Mobaro does not have a separate Asset category system layered on top of the hierarchy. The parent/child tree is the categorization mechanism. If you need cross-cutting groupings — e.g., "all electrical Assets across every ride in the park" — the right tools are:
Naming conventions applied consistently across Assets you want to find together (e.g., always prefix electrical Assets with
EL-).Location Groups bundling Locations that share characteristics, then granting team access via the Group.
A parent Asset structure repeated across analogous Locations, so similar Asset types live in similar tree positions everywhere.
Note: Reports and Dashboards filter on the explicit hierarchy, not on category metadata. Plan the tree so the cross-sections you actually need to report on can be expressed by selecting a parent Asset or set of parent Assets.
Anti-patterns to avoid
Watch out for these structural choices that create operational pain:
Targeting a parent Asset on a Schedule expecting children to be included — the most common surprise. Hierarchy does not cascade. If you want the work to apply to every component, target each Asset explicitly on the Schedule.
Going deeper than the team can navigate — past three or four levels, the tree starts feeling like a maze. Flatten where you can.
Inconsistent parenting across analogous rides or facilities — if Coaster A's electrical system has a "Control Panels" parent but Coaster B's electrical components are flat under Electrical System, anyone working both will struggle. Apply the same hierarchy template across analogous Locations.
Two children with identical names under different parents — Mobaro allows this (you'll see two "Eddy Brakes" rows in the list view, for example), but it creates ambiguity in conversations and reports. Use distinguishing names like Track Eddy Brakes and Electrical Eddy Brakes.
Trying to use the hierarchy as a category system for cross-cutting attributes — a single tree can only express one set of relationships. Don't try to model "by ride," "by manufacturer," and "by maintenance interval" all in the same tree.
See also
Creating an Asset — the create flow for individual Assets.
Linking Assets to Locations — for the Asset-to-Location scoping that underpins the hierarchy.
Asset-driven Assignments and Schedules — for how Assets work as Schedule and Assignment Targets, including the non-cascading behavior.
How to create Locations — for the Location side of the relationship.
How to create Location Groups — for cross-Location access patterns.
Frequently asked questions
Q: Does Mobaro support a native parent/child Asset hierarchy?
A: Yes. Every Asset can have one parent Asset (at the same Location) and any number of children. The hierarchy is shown as a tree in the Asset view and as Parent, Children, and Descendants columns in the Assets list.
Q: If I target a parent Asset on a Schedule, do all child Assets get the work too?
A: No. Hierarchy does not cascade to Schedule or Assignment Targets. Targeting Control Panels applies the Schedule only to Control Panels itself — not to MCC1, MCC2, or any other child. To run the Checklist on every component, you must target each Asset explicitly.
Q: How deep can the hierarchy go?
A: There's no hard limit, but most production hierarchies stop at three levels (System → Subsystem → Component). Past that, the tree becomes hard to navigate.
Q: Can an Asset's parent be at a different Location?
A: No. The hierarchy is scoped to a single Location — parent and child Assets must share the same Location.
Q: What's the difference between Children and Descendants on the Assets list?
A: Children is the count of direct children only. Descendants is every Asset below in the tree — children, grandchildren, and so on, all the way down. An Asset can have 4 children but 17 descendants if its branches go deeper.
Q: Can two Assets at the same Location have the same name?
A: Yes. Mobaro allows duplicate Asset names — for example, "Eddy Brakes" can exist as a child of Track Segments and another "Eddy Brakes" as a child of Electrical System. It's allowed but not recommended; distinct names make conversation and reporting easier.
Q: How do I move an Asset and its children to a new parent?
A: Use the move action on the tree toolbar. Select the Asset, click move, and pick the new parent. The Asset's full subtree (all descendants) moves with it.
Q: Does Mobaro have a separate Asset category or tag system?
A: No. The parent/child hierarchy is the primary organizing mechanism for Assets. Cross-cutting groupings should be expressed through hierarchy structure, naming conventions, and Location Groups.