Use the map to see how one person's access connects — use the table to search or audit across everyone.
Drag any node to rearrange, hover for detail. Click a platform access node (teal) to view its role history or request a change — dashed rings/links mark grants pending approval. SSO-backed grants auto-close on approval; shared/local and service-account grants require a person to record completion notes before the ticket closes.
Note: where "Licenses" has no standalone entries for a user, bundled licenses (e.g. Google Workspace, Microsoft Entra) are folded into that user's platform access rows instead.
Register a new system for this directory to sync. The account type is set by whoever connects it — this tool never auto-detects SSO vs local, since that's a fact about the target system, not something it can infer from an API response alone.
Each user's record in this directory is assembled by syncing these systems. This page never talks to them directly — a backend sync service holds the credentials and writes into one identity store, which this page reads.
A role is a named bundle of access across the sources above — defining it here is what lets "Request new role" (in a user's drawer) mean something concrete instead of a free-text label nobody can check. Roles are defined by an admin, applied to a person through the same ticket-approval flow as any other access change (Section 12), and never grant anything by themselves — a role definition is a template, not a live entitlement.
The HR feed (Workday) only knows people, so a service account, shared credential, or API key it never asks about shows up below with no owner at all. Defining a team here gives those accounts somewhere to be owned — by a group accountable for it, not by guessing which person to blame. This database lives only in this tool; it isn't synced from Entra or Google groups.
Accounts that exist in Entra, Google Workspace, or other systems but don't resolve to a person record from the HR platform — service accounts, API keys/app registrations, test accounts, and logins left behind by an incomplete offboarding. These sit outside the per-user map above and need separate review. Where one genuinely belongs to a team rather than a person (most service accounts and API keys), map it to a team below instead of leaving it ownerless.