Users & access

Users & access covers user administration, invitations, account status, login settings, roles, groups, access filters, SSO/OAuth2, and offboarding. Use this page when you are setting up the product surface, reviewing a rollout, or troubleshooting why users see a different result from an administrator.

What this surface is

• Primary purpose: user administration, invitations, account status, login settings, roles, groups, access filters, SSO/OAuth2, and offboarding.
• Where users start: Users are managed at /global-settings/users/list; older user detail routes also exist under /settings/users.
• Where administrators configure it: Roles and groups are managed at /global-settings/company/roles and /global-settings/company/groups; login policy is part of /global-settings/company/settings.
• Runtime/detail surface: Access rules decide what staff can see in objects, pages, reports, workflows, modules, and API-backed surfaces.
• Platform connections: User access connects authentication, tenant apps, namespace permissions, role filters, menus, teams, groups, and audit logs.

Where it lives

Area	Path or surface	Use it for
User surface	Users are managed at /global-settings/users/list; older user detail routes also exist under /settings/users.	Day-to-day work and review.
Configuration	Roles and groups are managed at /global-settings/company/roles and /global-settings/company/groups; login policy is part of /global-settings/company/settings.	Setup, permissions, routing, labels, and behaviour.
Runtime/detail	Access rules decide what staff can see in objects, pages, reports, workflows, modules, and API-backed surfaces.	Testing the live experience users actually see.

Configure it

1. Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
2. Open the owning product route: Users are managed at /global-settings/users/list; older user detail routes also exist under /settings/users.
3. Review the configuration route and permissions before changing live behaviour: Roles and groups are managed at /global-settings/company/roles and /global-settings/company/groups; login policy is part of /global-settings/company/settings.
4. Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
5. Configure User list, Roles, and Groups first because they shape the rest of the rollout.
6. Add Teams and Login settings only after the core path works with sample data.
7. Test the runtime surface as a restricted user, not only as a superadmin: Access rules decide what staff can see in objects, pages, reports, workflows, modules, and API-backed surfaces.
8. Check downstream connections after saving: User access connects authentication, tenant apps, namespace permissions, role filters, menus, teams, groups, and audit logs.
9. Record the owner, rollout date, and support path for the configuration.
10. Review the first week of activity and remove any option that users do not understand or need.

Configuration options

Option	Use when	Notes
User list	Admins manage people and invitations	Route: /global-settings/users/list.
Roles	Permissions should be reusable	Route: /global-settings/company/roles.
Groups	Membership should be reusable	Route: /global-settings/company/groups.
Teams	Work assignment follows teams	Route: /global-settings/company/teams.
Login settings	Authentication policy changes	Route: /global-settings/company/settings.
API apps	Code needs controlled access	Use application API settings and API keys.

Operating notes

• Keep labels aligned with the words users see in the product, especially User list and Roles.
• Permissions still matter even when a menu, page, or link is visible.
• If users see empty data, check role filters, enabled apps, ownership rules, and saved filters before editing records.
• If a change affects customers or public visitors, test from a logged-out or customer account as appropriate.
• Use reports or logs to confirm the change produced the expected operational result.
• Capture configuration decisions in rollout notes so support teams know what changed.
• Do not reuse one option for unrelated processes just because it is already configured.
• Review linked notifications, workflows, dashboards, and reports after changing this surface.
• Prefer narrow changes that can be tested with sample data before a tenant-wide rollout.
• When troubleshooting, start at the route users open, then inspect configuration, permissions, and logs in that order.
• Keep retired settings hidden or archived so users do not choose outdated paths.
• Assign an owner for ongoing review; unattended configuration becomes stale quickly.

For developers

Use these pages when the surface is read or changed by code, scripts, embeds, widgets, API clients, webhooks, or realtime listeners.

• /developer/authentication-classes
• /developer/api-applications-keys
• /developer/oauth2
• /reference/system-identity

Related links

• /guides/roles-permissions
• /guides/organisation-structure
• /guides/company-settings
• /guides/usage-logs