How Location scope fits into BuildWithHQ
BuildWithHQ location scope adds a second operational boundary inside the tenant. It works with DataRoles rather than replacing them: a user must have the correct role relationship and the record must also fall inside the user’s permitted location context.
Three-tier location rule
A user with no active location assignments is treated as having access to all tenant locations permitted by the user’s DataRoles.
A location-scoped user sees records assigned to those locations.
Records with no LocationId can remain visible when they are intentionally organization-wide and the DataRole permits access.
Where location scope applies
Contacts, conversations, assignments, unread state, SLA work, and follow-ups can remain inside the appropriate branch or region.
Events can be owned by users, tied to records, and associated with an operational location.
Any custom record using the universal RecordId can participate in the same location rules.
The application sends the user’s location context as a metadata filter before semantic search or AI context assembly.
Location scope continues to apply when users search, export, summarize, or automate records.
Operational examples
Nurses can be assigned to specific facilities while system administrators and approved doctors operate across the organization.
A franchisee sees its own locations; a regional operator sees a defined group; the franchisor sees the full network.
Dispatchers, technicians, and managers can be scoped by office, territory, depot, or service region.
Security behavior
Location scope is enforced by secured queries and procedures, not merely by hiding a location selector.
AI retrieval cannot use records from locations the user is not permitted to access.
Location assignments can be reviewed alongside temporal user, role, and record history when reconstructing past authorization.