Trust & Security
Tenant Data Security
How User Types, DataRoles, and Locations work together to shape an app experience and protect tenant data.
BuildWithHQ separates three questions that are often mixed together: what experience should this person see, what may they do with data, and which locations are in scope? User Types, DataRoles, and Locations answer those questions independently and are evaluated together for each signed-in user.
Three controls, three different jobs
| Control | Question it answers | Typical examples |
|---|---|---|
| User Type | Which menu, home/dashboard, and SaaS app pages should this kind of person be shown? | Owner, staff member, customer, field technician |
| DataRole | Which data may this person read, add, edit, delete, export, or use with AI, and which named actions may they perform? | Sales reader, support editor, billing approver |
| Location | Which assigned places are in this person's record scope? | All Locations, Las Vegas office, Reno office, or Las Vegas + Reno |
How they work together
Think of access as an intersection. The User Type shapes the visible app experience. DataRoles supply data and action grants. Locations narrow location-assigned records. Record-specific, field, secure-field, workflow, approval, and AI rules may narrow the result further.
For example, a user may have the Support Staff User Type, both Cases Reader and Case Editor DataRoles, and membership in the Las Vegas and Reno locations. Their menu can show support pages; their combined active roles can allow permitted case reads and edits; and location filtering limits location-assigned records to Las Vegas and Reno. None of those settings grants access outside the current SaaS app and tenant account.
The server resolves the final envelope
- The authenticated session establishes the SaaS app, tenant account, and active user.
- The user's User Type selects the intended menu, portal/dashboard, and page experience.
- All active DataRole memberships and granular permission keys are resolved.
- The user's All Locations, single-location, or multi-location scope is resolved.
- The requested record, field, and action are checked again before data is returned or changed.
The browser never proves its own tenant, role, location, or user identity. Those values come from the verified server session, and reviewed stored procedures apply the final data checks.
Route eligibility and data authorization
A User Type's dashboard and primary menu establish which SaaS page routes that audience may open. When a current User Type has a primary menu, a direct request for an unassigned page is rejected. Every eligible page component, search, download, API call, AI retrieval, and mutation is then authorized independently with DataRole, Location, record, field, and action rules.
Assigning a page makes its route eligible for the User Type. It does not grant the data or actions displayed by that page.
A practical review checklist
- Give each person the User Type whose menu matches their job.
- Assign only the DataRoles needed for that job; remember that grants from multiple roles combine.
- Use All Locations only for people who genuinely need tenant-wide location access.
- Assign one or multiple named locations for regional or office-scoped users.
- Test assigned and unassigned direct routes as representative users, then test search, exports, AI, records, fields, and writes on eligible pages.