> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/sync-identities.md). # Sync Identities Synchronizes identity attributes between systems, with options to: * Create new identities if they don't exist * Update attributes of existing identities * Enable continuous sync to keep attributes aligned with the source of truth **Example Use Cases:** * Create new user accounts in target systems when employees join * Update user attributes when information changes in HR systems * Ensure consistent user information across multiple platforms | Setting | Description | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Entity Type | The data source and type of identity to sync (e.g., Okta User, Azure AD User) | | Don't create new users | When checked, identities that don't already exist are skipped. Leave unchecked (the default) to create a new identity when none is found. | | Attribute Sync | Keep attributes in sync even after initial creation | | Common Synced Attributes | Shared transformation rules across multiple sync actions | | Action Synced Attributes | Create, format, and modify the specified target attributes. See [Transformers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers.md) for more details | | Unique Identifier | The attribute Veza uses to locate an existing user when syncing. Defaults to the integration's primary identifier (for SCIM integrations, `userName`) | | Enforce password change on login | Force newly created users to change their password at first login. Availability varies by target system — see [Enforce password change on login](#enforce-password-change-on-login). | **Password output (Early Access)** When password output is enabled, the password generated during identity creation is available to subsequent workflow actions via transformer expressions. Use `{EntityType.password}` syntax to reference it, such as `{OktaUser.password}` in a Send REST Payload action. This is useful in joiner workflows where Veza provisions a new account and needs to pass the generated password to a downstream system such as an HR portal or ticketing API. {% hint style="warning" %} Passwords are passed as plain text to downstream actions. Use this only when the workflow requires it, and ensure receiving endpoints use HTTPS. Passwords are never written to the Veza database. They are available in memory during workflow execution only and are redacted from stored job payloads before persistence. {% endhint %} {% hint style="info" %} **Early Access:** Password output requires the `LCM_INCLUDE_PASSWORD_IN_OUTPUT_ENTITIES` feature flag. Contact Veza support to enable it for your tenant. {% endhint %} ## Write back to an identity source A Sync Identities action can target one of the policy's own identity sources, updating the system of record instead of a downstream application. Use this to push a value the workflow produced, most often an email address, back into an HR system such as Workday. When you select a target that is also an identity source on the policy, the action switches to write-back mode automatically and shows **Writing back to Identity Source**. In this mode: * Creating new identities is disabled. A write-back action only updates records that already exist. * Guest account creation and invitations are hidden. * The attributes you can map are limited to those the identity source accepts as writable. Which attributes are writable depends on the integration. Workday, for example, accepts `username` and `email` on the Workday Account entity, and applies the `email` value to the linked worker's primary work email. See [Workday provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/workday/provisioning.md#sync-identities). To configure one, map the unique identifier plus each attribute you want to write. Veza uses the unique identifier to locate the record, and the action fails if the mapping omits it. For a Workday email write-back, the minimum mapping is `id` and `email`. {% hint style="info" %} Writing an email back to an HRIS this way is different from the [Write Back Email](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/write-back-email.md) action. Write Back Email pushes the address a previous action just created and takes no attribute mapping. A write-back Sync Identities action lets you set the attribute to any value with a transformer. See [Choosing between Write Back Email and Sync Identities](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/write-back-email.md#choosing-between-write-back-email-and-sync-identities). {% endhint %} ## Referencing attributes from earlier actions A Sync Identities action makes the target account's attributes available to later actions in the same workflow. Reference them by qualifying the attribute with the entity type: ``` {ActiveDirectoryUser.email} {AzureADUser.principal_name} ``` A bare placeholder such as `{email}` reads only the source-of-identity record that triggered the workflow, so it does not return values the workflow wrote to a target system. Use the qualified form for that. When several actions write the same entity type, the most recent value takes precedence. This is what makes a two-step write-back possible: provision the account in the target system, then map the identity source's `email` attribute to the address the first action produced. After a [Create Email](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/create-email.md) action, the new address is also available to every later action as `{email_address}`. Three limits apply: * **Order matters, and Veza does not check it.** Unlike the [Write Back Email](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/write-back-email.md#required-upstream-action) action, a Sync Identities write-back action is not validated for ordering. Placed before the action that produces the value, it publishes without error and then writes an empty or stale value at run time. Structure the policy so that the write-back occurs after the action that creates the account. * **A sync that changes nothing might not publish its mapped values.** When an action finds the target already up to date, later actions see only the attributes the target system itself returned, not every mapped field. * **Available attributes vary by integration.** For example, Active Directory re-reads the account after writing, so `{ActiveDirectoryUser.email}` reflects the stored value. Azure AD returns the user principal name but not `mail` (use `{AzureADUser.principal_name}` to retrieve the address of a newly created Azure AD account). ## Enforce password change on login **Enforce password change on login** forces a newly created user to change their password the first time they sign in. The checkbox appears on the Sync Identities action only for target systems that support it. | Target system | Sync Identities | Reset Password | | ---------------- | --------------- | ---------------------------- | | Active Directory | ✅ | ✅ | | Azure AD | ❌ | ✅ | | Google Workspace | ✅ | — (no Reset Password action) | For Active Directory, this setting is part of a broader password policy that also controls password complexity and can deliver the generated password through an event notification — see [Active Directory provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/active-directory/provisioning.md#password-policy-for-new-identities). For Google Workspace, only the change-on-login behavior is configurable — see [Google Cloud provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/google/provisioning.md#password-policy-for-new-identities). For the Reset Password action, see [Reset Password](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/reset-password.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/sync-identities.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.