How to Build a Location Hierarchy

How to build a location hierarchy

Locations nest to any depth through a parent reference, inside a Site. The hierarchy describes places within an operational site — not the sites themselves.

Sites answer "where does the organization operate?" Locations answer "where physically inside that site is the asset?" Manage sites at Dashboard → Sites.

Requirements

• Available on: All plans
• Roles: Owner, Admin, and Manager can create and edit (same permissions as assets). Archive and delete need Owner or Admin.

How nesting works

Each location belongs to exactly one site and can have a parent location in the same site.

Site: Manchester Campus
 ├── Building A
 │    ├── Floor 1
 │    └── Floor 2
 │         ├── Room 204
 │         └── Room 210
 └── Building B
      └── Workshop

A root location (Building A above) has no parent, but it is still a Location under the Site — it is not a Site.

Building it

Create the Site first, then build locations top down: buildings, then floors, then rooms. Child locations inherit their parent's site automatically.

You do not have to build the whole tree before adding assets. Start with the depth you need — many organizations run happily on building → room.

Common patterns

Pick one and apply it consistently. The value is in the consistency, not the shape.

For multiple operational places (two plants, two campuses), create separate Sites, each with its own location tree — do not encode the site name into every location.

Depth

Two to four levels covers most organizations.

Going deeper costs you on every asset form, because someone has to pick the right leaf. Going shallower costs you on filtering, because "Building A" tells you less than you need.

The test: if nobody will ever filter at a level, that level does not need to exist.

Consistency across branches

Use the same levels everywhere. If Building A has floors and Building B goes straight to rooms, then "everything on floor 2" is a question you cannot ask across the estate.

Where a building genuinely has no floors, it is usually better to create a single nominal level than to leave the branch shallower than its siblings.

Reorganising

Locations can be re-parented within the same site as your estate changes. Assets stay where they are — they are attached to the location, not to its position in the tree. You cannot move a Location under a parent in a different Site.

Locations can be archived or, when empty, deleted. Move the assets out before either action.

Common mistakes

Encoding the hierarchy in names. "Manchester – Building A – Floor 2 – Room 204" as one location defeats the point. Nest them under a Site.

Treating root locations as sites. After Sites exist as a first-class entity, root locations are just locations without a parent.

Mixing in departments. "Floor 2 – Finance" breaks when Finance moves. Departments are a separate structure.

Creating shelf-level detail. Bin-location tracking is a warehouse management problem; UniAsset is not a warehouse management system.

Building the perfect tree before adding assets. Time-to-first-asset matters more. Add depth when you need it.

Troubleshooting

Filtering by a parent returns nothing. Check the assets are actually filed against a descendant rather than against the parent.

I can't set a parent. Check the intended parent is not archived and belongs to the same site.

I can't create a location. It needs a Site, and you need Owner, Admin, or Manager create permission.

The name is already taken. Location names must be unique among siblings under the same parent. The same name can exist under different parents or in different sites.

My hierarchy has grown unmanageable. Archive the levels nobody filters on and move the assets up. Archiving is reversible.

Related articles

• How to create and manage locations
• Categories, sites, locations and departments
• How to move assets between locations
• Location reports
• Categories, locations and departments explained
• Organization structure best practices