Users and access
Provision a tenant user using the practical company-role templates, site scope and classification clearance. The UI simplifies assignment but does not replace server-side technical permission checks.
Screen orientation
Only company administrators with the required tenant authority can create, reset or change a user. Platform administration is separate.
Search/sort the user register, open a user to review current access, then use the create/edit panel to set identity, role bundle, site scope, clearance and initial authentication state.
Field reference
The entries below describe the current screen controls and read-only values. They do not relax server-side validation, site scope, classification handling or required independence in a governed decision.
| Field or value | Control | Required or shown when | How to use or read it | Result |
|---|---|---|---|---|
| Display name | Text | Required. | Use the person’s recognisable operating name. Do not use a shared team alias for an accountable user. | Appears in attributable activity and decision history. |
| Username / email | Text | Required; must be a unique sign-in identity. | Enter the individual’s controlled sign-in identifier. It is not a supplier portal or platform-admin identity. | Creates the tenant sign-in identity. |
| Initial password | Password | Required on initial provisioning or authorised reset. | Provide through the approved secure onboarding path; do not record it in notes, documents or chat. | Sets the temporary authentication secret; the value is never displayed later. |
| Company role | Select | Required. | Choose the smallest practical role bundle matching the person’s work. Advanced control authorities remain separately governed. | Expands to the existing technical permissions; it does not bypass maker-checker rules. |
| Site scope | Multi-select | Required for operational access. | Grant only sites the person is authorised to work in. UI visibility never overrides API site enforcement. | Limits site-bound data and actions. |
| Clearance | Select | Required. | Set the highest authorised classification clearance—not a desired future level. | Limits visibility/readability alongside document and record classification. |
Actions and effects
When to use: After identity, role, site and clearance have been reviewed.
What it does: Provisions the tenant user and its mapped permissions; it does not change any existing business record.
When to use: When authorised administration is necessary.
What it does: Updates the user’s authentication/access state and retains attributable administration evidence.
Lists and states
- User register: identity, status, role presentation, sites and clearance show assigned access—not proof the person can perform every workflow decision.
Authority boundary
This screen manages tenant access. It cannot impersonate a user, bypass MFA policy, grant platform administration or replace named maker-checker separation.