> 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/write-back-email.md).

# Write Back Email

Update HRIS systems with email addresses created during onboarding workflows.

Updates an HRIS or identity source with an email address created earlier in the same workflow. This ensures the source of identity (such as Workday) contains the employee's new corporate email address, and keeps records consistent across systems.

The address comes from an upstream action, usually [Create Email](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/create-email.md). This action has one setting, Entity Type: you choose where the address is written, not what gets written. It writes the address the upstream action produced without modifying it, so you cannot select among several addresses or reformat one. To set the identity source's email to a value you choose, use [Sync Identities](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/sync-identities.md#write-back-to-an-identity-source) instead.

**Example Use Cases:**

* After creating an Exchange Server mailbox during onboarding, write the new email address back to the Workday Worker record
* Update an OAA-based HRIS source with email addresses generated by provisioning workflows

| Setting     | Description                                                                                     |
| ----------- | ----------------------------------------------------------------------------------------------- |
| Entity Type | The HRIS or identity source entity type to update with the email address (e.g., Workday Worker) |

**Supported Integrations:**

| Integration     | Notes                                                                                |
| --------------- | ------------------------------------------------------------------------------------ |
| Workday         | Writes email to the Worker record via the Workday API                                |
| Oracle HCM      | Writes email to the Oracle HCM employee record                                       |
| HiBob           | Writes email to the HiBob employee record                                            |
| OAA Custom HRIS | Writes email to custom HRIS identity providers integrated via Open Authorization API |

{% hint style="info" %}
Write Back Email writes only to an HRIS or identity source. To set an email attribute on a target application such as Active Directory or Okta, use [Sync Identities](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/sync-identities.md) with an email attribute transformer.
{% endhint %}

## Required upstream action

A workflow containing a Write Back Email action must also contain an action that produces an email address, earlier in the same workflow branch. Two kinds of action qualify:

* A **Create Email** action.
* A **Sync Identities** action against an integration that provisions a mailbox as part of the sync. Google Workspace is the only integration that provisions a mailbox this way.

Veza checks this when you publish or update the policy and rejects a workflow that does not satisfy it, rather than letting it fail during a run. This check applies to Write Back Email actions only, and it validates the structure of the workflow rather than what happens during a run. A workflow that passes the check can still fail at run time. If a condition skips the upstream action, or its sync does not surface the provisioned address, the Write Back Email action records an `ACTION_FAILED` event in the activity log.

This requirement is why a workflow that provisions Active Directory or Azure AD from Workday cannot use Write Back Email unless it also creates a mailbox. Provisioning an Active Directory or Azure AD account does not by itself produce an email address that this action can write. To write an address back to Workday in those workflows, map `email` on a write-back [Sync Identities](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/sync-identities.md#write-back-to-an-identity-source) action.

## Choosing between Write Back Email and Sync Identities

Both can set an identity source's email address, and for Workday both write the same field. They differ in where the value comes from.

| Behavior             | Write Back Email                            | Sync Identities (write-back mode)                     |
| -------------------- | ------------------------------------------- | ----------------------------------------------------- |
| Value written        | The address an upstream action just created | Any value you map with a transformer                  |
| Attribute mapping    | None. You pick only the entity type         | Full transformer support                              |
| Upstream requirement | Create Email, or a Google Workspace sync    | None                                                  |
| Creates identities   | No                                          | No, disabled in write-back mode                       |
| Workday target       | Workday Worker, directly                    | Workday Account, writing through to its linked worker |

Choose **Write Back Email** when the workflow provisions the mailbox and you want that address in the HRIS. Choose **Sync Identities** when the authoritative address comes from another system: an account Veza created in Active Directory or Azure AD, a downstream IdP, or another HRIS field.

## Example: Exchange Server onboarding with email write-back

In a typical Workday-to-Active Directory onboarding workflow, Write Back Email is the third step:

1. **Sync Identities** creates the AD user account from the Workday Worker.
2. **Create Email** creates an Exchange Server mailbox, generating the email address.
3. **Write Back Email** writes the new email address back to the Workday Worker record.
4. A second **Sync Identities** action, targeting Active Directory and mapping only `email`, sets the address on the AD user account.

This ensures that the Workday record reflects the employee's corporate email immediately after onboarding, without manual HR data entry.

For the full workflow configuration, see the [provisioning example](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions.md#example-conditions-and-actions-provisioning-to-active-directory) in the Actions overview. For Exchange Server setup, see [Exchange Server Provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/exchange-server/provisioning.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/write-back-email.md?ask=<question>&goal=<endgoal>
```

`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.