# User Data Model ### πŸ“– **Key Concepts** Every **user** **record** in Cakewalk has four core attributes: 1. **Source:** Where the identity came from (HRIS, IDP, Integration, Manual) 2. **Category:** The type of user (Employee, Contractor, Service Account) 3. **Role:** What permissions they have within Cakewalk 4. **Status:** Whether the identity is actively governed Together, these define how Cakewalk manages, displays and governs human identities. {% hint style="info" %} **About non-human identities (NHIs)** Cakewalk stores NHIs (such as bots and service accounts) in a separate entity, not in the User model. See [NHI Data Model](/concepts/data-models/nhi-data-model.md). {% endhint %} ### πŸ“‚ **User Fields** | Field | Description | Examples | | ----------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | **Primary Email** | Unique identifier for the user (always included in aliases list). | | | **Aliases** | Additional email addresses linked to this user. | , | | **Source** | Origin of the user record (see [below](#user-sources)). | HRIS, IDP, Integration, Manual | | **Status** | Governance state (see [below](#user-statuses)). | Active, Discovered, Ignored, Tracked[^1], Onboarding, Invited, Deactivated[^2] | | **Category** | Classification of the user (see [below](#user-categories)). | Employee, Contractor, Service Account | | **Role** | Permissions level inside Cakewalk (see [here](/concepts/cakewalk-roles-and-permissions.md)). | General Manager, Admin, User | | **App Accesses** | List of accounts discovered for this user across connected applications. | Slack, GitHub, Notion, ChatGPT, etc. | | **Department** | The department, function or business unit the user belongs to. | Engineering, Sales, Finance | | **Manager** | The user’s direct manager (used in request and approval workflows). | | ### 🌐 **User Sources** Each user has a **Source** that indicates where they were first discovered or synced from: | Source | Description | Example | | ----------------------------- | ------------------------------------------------------------------------ | ---------------------------------------------------------------- | | **HRIS** | Synced from your system of record (e.g. BambooHR). | Jane exists in BambooHR β†’ synced to Cakewalk | | **IdP** | Synced from your identity provider (e.g. Okta, Entra, Google Workspace). | John added to Okta β†’ synced to Cakewalk | | **Integration** (coming soon) | Discovered via a SaaS app integration. | GitHub user not found in HRIS/IDP but synced to Cakewalk | | **Manual** | Created manually in Cakewalk. | Admin creates a user manually who is not part of the HRIS or IdP | ### πŸ‘₯ **User Categories** Each user in Cakewalk is assigned a **Category** that classifies the type of user: | Category | Description | Example | | ------------------- | --------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | | **Employee** | Full-time or part-time employees of the organization. | Jane Doe, Software Engineer at the company | | **Contractor** | External workers, consultants, freelancers or temporary staff who need access to company apps for a fixed term. | John Smith, freelance designer working on a 3-month project | | **Service Account** | User-category service account records that may exist in legacy/manual user management flows. | Shared engineering account, legacy automation account | Non-human identities are represented in the separate NHI entity and surfaced in dedicated NHI views. See [NHI Data Model](/concepts/data-models/nhi-data-model.md). ### :vertical\_traffic\_light: **User Statuses** Statuses control whether users are governed, visible and able to take action.
StatusStatusCan Submit Request?Can Access Cakewalk?Included in Access Reviews?
DiscoveredFound in integration but not linked to a Cakewalk user or invited yet.❌ No❌ No❌ No
InvitedUser is invited to Cakewalk but still needs accept it to turn active.❌ Noβœ… Yesβœ… Yes
ActiveFully governed user with valid role.βœ… Yesβœ… Yesβœ… Yes
IgnoredExplicitly excluded from governance.❌ No❌ No❌ No
OffboardingOffboarding for the user has begun and they only have limited access to Cakewalk.❌ Noβœ… Yes❌ No
DeactivatedCompletely offboarded users, retaining request logs for audit purposes.❌ No❌ No❌ No
#### **Example: Discovered β†’ Active** 1. Cakewalk syncs from GitHub and finds . 2. Alex does not exist in HRIS/IDP β†’ marked **Discovered**. 3. Admin confirms Alex is a contractor β†’ sets status to **Active**, assigns role **User**. 4. Alex is now included in access reviews and can request apps. *** ### πŸ”„ **Status Transitions** Admins can manually transition users between statuses. Common transitions include: * **Discovered β†’ Active** (onboard a previously unmanaged user) * **Discovered β†’ Ignored** (suppress irrelevant identities) * **Active β†’ Offboarding** (start deprovisioning workflow) [^1]: Is missing in the table below. Do we support this status initially, [max.applin](mailto:undefined)? [^2]: Also missing in the table below, [max.applin](mailto:undefined) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.getcakewalk.io/concepts/data-models/user-data-model.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.