Overview
Location Properties are tags you assign to Locations to describe their characteristics — ride type, equipment present, area of the park, regulatory category, etc. Properties live inside Categories, and a Location can have multiple Properties across multiple Categories. Once assigned, Properties drive conditional logic on Checklists, filtering in Reports and Dashboards, and grouping across the Mobaro Backend. This article covers creating Categories and Properties, assigning them to Locations, and the places that data shows up downstream.
Users must be Super Users or have the following Role to manage Location Properties:
Organization: Administrate
Why this matters: Without Location Properties, every variation in your operation needs its own dedicated Checklist, Schedule, or Report. Properties let one Checklist behave differently across Locations — track inspections appear only on coasters, water-quality questions only on water rides, climbing-equipment checks only on FECs with climbing walls. The same logic applies to reporting and filtering. Less duplication, less drift.
Categories and Properties
Location Properties are organized in two layers:
Object | What it is | Example |
Category | A grouping that holds related Properties. Categories are how you keep different attribute axes separate. | Ride Type, Equipment, Park Area |
Property | A specific tag within a Category that you can assign to one or more Locations. | Under Ride Type: Coaster, Flat Ride, Water Ride, Kiddie Ride |
Note: A Location can hold multiple Properties across different Categories — for example, Ride Type: Coaster, Park Area: North Park, and Equipment: VR Headsets all on the same Location. Within a single Category, you typically pick one Property per Location, though Mobaro doesn't enforce that — assign as many as make sense for your operation.
Creating Categories and Properties
1. Open Configuration
In the Mobaro Backend, navigate to Configuration > Locations.
2. Add a category
Click + Add category and enter a descriptive name (e.g., Ride Type). Categories should each represent a single attribute axis — separate Categories for ride type, equipment, park area, and so on.
3. Add Properties to the category
Under the new Category, click + Add property. Enter the Property name (e.g., Coaster, Flat Ride, Water Ride). Repeat for each Property the Category needs.
Best practice: Use clear, unambiguous Property names that anyone reading them — operations leadership, frontline staff, reviewers — would understand the same way. Avoid abbreviations and ambiguous phrasing. Coaster beats RC; Climbing Wall beats CW.
Assigning Properties to a Location
1. Open the Location
In the Mobaro Backend, navigate to Locations and select the Location you want to tag.
2. Open the Location editor
Click Edit on the Location.
3. Set Location Properties
Scroll to the Location Properties section. Use the dropdowns for each Category to check the Properties that apply to this Location.
4. Save
Click Save on the Location editor.
Critical: Changes to Location Properties take effect immediately and can change how Checklists behave for that Location. Removing a Property may hide questions that were previously visible; adding a Property may surface new questions or requirements. Review the affected Checklists before changing Properties on production Locations.
Where Location Properties show up
Once Properties are created and assigned, they're consumed in several places:
Checklist conditional logic — Questions, sections, and entire Checklists can be set to show only when a Location has (or doesn't have) specific Properties. See Using Location Properties as Checklist logic.
Location records — Every assigned Property appears in the Location's Location Properties section, giving anyone with access a quick read on the Location's characteristics.
Example: one Checklist across four ride types
Scenario
A regional theme park runs a single Pre-Opening Inspection Checklist across every ride. The current Checklist is bloated — it contains every question for every ride type, and operators end up answering N/A to questions that don't apply to their ride. Maintenance can't tell what was actually inspected versus skipped.
Setup
Create a Ride Type Category.
Add four Properties: Coaster, Flat Ride, Water Ride, Kiddie Ride.
For each ride Location, open the editor and check the appropriate Property in Location Properties.
Update the Pre-Opening Inspection Checklist to use Property-based logic: track-tension questions show only on Coaster Locations; water-pH questions only on Water Ride; height-restriction signage check only on Kiddie Ride; etc.
Result
Each Location now sees only the questions that apply to its ride type. Coaster operators no longer scroll past 20 water-ride questions; water-ride operators see chemistry checks they would have missed.
A new ride can be onboarded by creating the Location and tagging it with the right Property — no Checklist editing required.
Reports and Dashboards can now break Downtime, throughput, and inspection data down by ride type, surfacing patterns that were previously buried in the all-rides aggregate.
Frequently asked questions
Q: Can a Location have multiple Properties?
A: Yes. A Location can hold any combination of Properties across different Categories — and within a single Category if your operation needs that.
Q: What happens if no Properties are assigned to a Location?
A: Any Checklist content not gated by Property logic still applies. Property-gated content simply doesn't appear. The Location functions normally; it just doesn't trigger Property-conditional logic.
Q: Can I rename or delete a Property after Locations are using it?
A: Yes, but with care. Renaming a Property updates it everywhere it's referenced. Deleting a Property removes it from every Location and may break Checklist logic that depended on it. Audit Checklists before deleting.
Q: Are Property names unique across Categories?
A: Yes — within Mobaro, Properties are scoped to their Category to keep them logically grouped. Two Categories can't reuse the same Property name.
Q: Do Location Properties affect User access?
A: No. Properties describe Locations, not Users. Access to a Location is governed by the User's Role and Location assignments — not by Properties.