---
title: "Locations: where tenant data is assigned"
section: "Trust & Security"
canonical_url: "https://support.buildwithhq.com/trust/locations.html"
reviewed_at: "2026-09-14"
authority: Official
---

# Locations: where tenant data is assigned

Locations define where records belong and whether a person works across all, one, or multiple tenant locations.

## In brief

- **Controls:** Location-assigned record scope
- **People:** All, one, or multiple locations
- **Records:** Named location or location-neutral

A **Location** describes where tenant data is assigned: an office, branch, property, region, service area, or other place meaningful to the business. Records can be assigned to a named Location, and people can work across All Locations, one Location, or multiple Locations.

[Tenant Data Security](tenant-data-security.html) [User Types](user-types.html) [DataRoles](data-roles.html)

## The three location states

| Person's scope | Assignment | Location records in scope |
| --- | --- | --- |
| **All Locations** | No named-location restriction | Las Vegas, Reno, future tenant locations, and location-neutral records, subject to DataRoles. |
| **One Location** | For example, Las Vegas office | Las Vegas and location-neutral records, subject to DataRoles. |
| **Multiple Locations** | For example, Las Vegas + Reno | Las Vegas, Reno, and location-neutral records, subject to DataRoles. |

In the current security contract, All Locations is the absence of named user-location restrictions, not a special wildcard Location record. One or more user-location assignments make the person location-scoped. Location-neutral records have no Location assigned and remain available across location scopes when the person's DataRoles allow them.

## Primary and additional Locations

A multi-location user can have one assignment marked primary. The primary Location can provide a sensible default for creation or filtering, while the full assignment set defines the named Locations in scope. Marking a Location primary does not by itself grant a broader DataRole.

## Location works with DataRoles

Location answers *where*; DataRole answers *what action*. A Las Vegas user still needs a DataRole that permits reading a customer record. An All Locations user with a read-only role still cannot edit it. Both dimensions must allow the requested operation.

## Assigning records

- Assign location-specific records, such as office work orders or regional customers, to the appropriate Location.
- Leave truly tenant-wide records location-neutral rather than inventing a fake global office.
- Only allow a user to create or move a record into a Location authorized for that user and operation.
- Apply the same scope to lists, detail pages, global search, relationships, files, exports, notifications, and AI retrieval.

Important

All Locations is powerful. Use it for tenant-wide responsibilities, not as a convenience when a person's actual offices have not yet been assigned.

## Example

Jordan belongs to Las Vegas and Reno, with Las Vegas marked primary. Jordan can work with records assigned to either office and with tenant-wide location-neutral records, but not records assigned only to Phoenix. What Jordan can do with the in-scope records still comes entirely from Jordan's active DataRoles and the record's other security rules.

---

Capability review: 2026-09-14. [View the canonical guide](https://support.buildwithhq.com/trust/locations.html).