Trust & Security
User Types: menus and SaaS pages
User Types define the menu, landing experience, and SaaS app pages each kind of person is shown.
A User Type describes the kind of app participant a person is. It determines the navigation and SaaS page experience intended for that audience: which menu is loaded, which entries it contains, and which portal or dashboard is used as the starting point.
What a User Type defines
- Menu: the ordered navigation items shown to that type of user.
- SaaS pages: the pages linked into that audience's app experience.
- Starting experience: the portal and dashboard/home page associated with the type.
- Audience shape: a stable key and friendly name that templates and menus can use.
Examples might include Owner, Office Staff, Field Technician, Customer, or Vendor. These are app-design choices, not universal built-in authorization levels.
One person, one current User Type
Each tenant user has one current User Type. Many people can share the same type, and each type can have its own menu. A page may appear in more than one type's menu, appear in different positions, or be absent from a type entirely.
Menus and pages define route eligibility
User Types define what a person is shown and which SaaS page routes belong to that audience. When the User Type has a primary menu, its dashboard and assigned menu pages are eligible; a direct URL to an unassigned page is rejected by the server.
This presentation boundary does not decide which records or fields the person may read or change. DataRoles, Locations, record and field rules, and action-specific permissions remain responsible for authorization on every eligible page.
A page can be assigned to several User Types without duplicating it. Each signed-in person still receives only the data allowed by their own permission envelope.
Designing User Types
- List the distinct audiences that use the app.
- Give each audience the smallest useful menu and a clear starting page.
- Reuse pages across types when the workflow is shared; do not duplicate a page merely to change data access.
- Assign DataRoles and Locations separately for each person's actual responsibilities.
- Test assigned and unassigned direct-page behavior as a real user of each type, then test the data and actions on each eligible page.
Name User Types for the experience they receive, such as Customer Portal or Field Technician. Name DataRoles for the permission they grant, such as Cases Reader or Work Orders Editor.