When you provision hybrid users into Active Directory from Workday and synchronize them to Entra ID via Cloud Sync, you quickly hit a wall: Cloud Sync cannot write otherMails. The attribute exists only on the Entra ID user object — there is no AD equivalent — and Cloud Sync has no mechanism to write cloud-only properties on the accounts it syncs.
For many organizations this matters because otherMails is the personal email address that powers day-one SSPR. Without it populated at account creation, new employees cannot reset their own password until they complete a self-registration flow — which typically requires them to already be logged in.
otherMails is the Entra ID attribute that SSPR uses as the "Alternate email" reset method. When populated before the user's first login, it enables password reset without prior registration. The personal email originates in Workday's personalEmail field and needs to reach this attribute on the cloud user object.
The Problem in Detail
Here is the flow for a typical hybrid provisioning setup, and where it breaks down:
Workday → AD (Connector 1)
The Workday inbound provisioning connector creates the user in on-premises Active Directory. It maps PreferredFirstName, LastName, Department, EmployeeID, and other standard attributes. Personal email can be written to an AD extension attribute (e.g. extensionAttribute1) but AD has no otherMails property.
AD → Entra ID (Cloud Sync)
Cloud Sync syncs the AD user to Entra ID. It creates the cloud representation of the user with all standard attributes. However, otherMails is a multi-value string array that Entra ID computes and manages — Cloud Sync does not write it. Even if personal email is in extensionAttribute1, there is no supported mapping from that attribute to otherMails in Cloud Sync.
otherMails remains empty
The hybrid user lands in Entra ID with no otherMails value. SSPR works only if the user has previously registered, which requires an active account. Day-one password reset fails.
This is the second connector pattern. You deploy a second enterprise application of type "API-driven provisioning to Microsoft Entra ID" (or the Workday → Entra ID cloud connector if you are using the native Workday integration), configured with one critical difference from the primary connector:
Create action: OFF. Update action: ON. The connector will only ever match existing accounts and write to them. It will never attempt to create a new user object, regardless of what Workday sends.
Connector Roles Side by Side
Workday → Active Directory
- Creates hybrid AD accounts
- Writes all standard AD attributes
- Manages OU placement
- Enables / disables accounts
- Manages manager attribute
- Handles UPN generation
Workday → Entra ID (update only)
- Create: OFF
- Matches on
employeeId - Writes
otherMailsfrom WorkdaypersonalEmail - Can also write
usageLocation, custom extension attributes - Writes any cloud-only property invisible to Cloud Sync
Attribute Mapping Configuration
In the Entra admin center, navigate to the second provisioning app's attribute mappings and configure the following. Keep mappings minimal — only include what this connector is responsible for.
| SOURCE (WORKDAY) | TARGET (ENTRA ID) | APPLY MAPPING | NOTES |
|---|---|---|---|
WorkerID | employeeId | MATCH ATTRIBUTE | Used for account matching only — stable Workday identifier |
personalEmail | otherMails | ALWAYS | Core purpose of this connector |
CountryISO | usageLocation | ALWAYS | Optional — also not writable via Cloud Sync |
| (remove all others) | — | — | Strip default mappings — this connector should be narrow in scope |
When you create the provisioning app, it comes with a full set of default attribute mappings. Delete all of them except the match attribute and otherMails. If you leave displayName, userPrincipalName, or other attributes mapped, this connector will overwrite values that the primary connector and Cloud Sync are responsible for — potentially causing conflicts and provisioning loops.
Scoping Filter — The Critical Safety Guard
Without a scoping filter, this connector will attempt to process every worker in Workday — including cloud-only users who are already fully managed by a separate cloud-only connector. That creates a race condition where two connectors both write to the same user object.
The scoping filter must match only the hybrid population. Use the same attribute you use to differentiate hybrid from cloud-only workers in Workday — typically Worker_Type, Legal_Entity, or a custom boolean field.
// Scoping filter in the provisioning app — Workday attribute filter
// Only process workers that are in scope for hybrid AD provisioning
Attribute: Worker_Type
Operator: EQUALS
Value: "Employee"
// AND
Attribute: Legal_Entity
Operator: MEMBER_OF
Value: "Contoso Corp", "Contoso LLC"
// This must mirror the scoping filter on Connector 1 exactly.
// If a worker is in scope for Connector 1 (AD creation),
// they must also be in scope for Connector 2 (attribute enrichment).
The scoping filter on Connector 2 (hybrid attribute writer) and your cloud-only connector must be mutually exclusive. A worker should appear in exactly one connector's scope for update operations. Use the same attribute and values you defined when splitting the two provisioning agents — the same logic that prevents UPN collision applies here.
Provisioning App Settings
In the provisioning app settings, set the following:
// Provisioning app settings (Provisioning > Settings blade)
Provisioning Mode: Automatic
// Under Mappings > Provision Workday Users
// In the attribute mapping header, set:
Create new objects: OFF ← critical
Update matching objects: ON
Delete matching objects: OFF ← never let this connector deprovision
// Matching attribute
Source object attribute: WorkerID // Workday
Target object attribute: employeeId // Entra ID
Match precedence: 1
What Happens at Runtime
When the provisioning cycle runs for Connector 2:
Worker record read from Workday
The connector reads the worker's WorkerID and personalEmail from the Workday data view.
Match against Entra ID by employeeId
The provisioning service queries GET /users?$filter=employeeId eq 'WD-12345'. If no match is found — because the AD account has not synced yet — the record is escrowed and retried on the next cycle. No account is created.
PATCH otherMails via Graph
The provisioning service issues PATCH /users/{id} with { "otherMails": ["personal@gmail.com"] }. This is a direct Graph write — not through AD, not through Cloud Sync.
SSPR is now available on day one
With otherMails populated, the user can reset their password using the alternate email method before their first login — no prior registration required.
Timing Consideration
Connector 2 depends on the account already existing in Entra ID before it runs. The account creation sequence is:
- Connector 1 creates the user in AD
- Cloud Sync syncs the AD user to Entra ID (~20–40 minutes)
- Connector 2 runs its next cycle (~40 minute interval) and finds the account
otherMailsis written
In the worst case, otherMails is populated about 80 minutes after account creation. For pre-hire provisioning (account created 1–3 days before start date), this is not an issue. If same-day provisioning is required, a Lifecycle Workflow Logic App custom extension triggered at joiner time is a faster alternative — it fires immediately after the account appears in Entra ID and makes the same Graph PATCH call.
If you need otherMails populated within minutes of account creation rather than on the next 40-minute provisioning cycle, deploy a Lifecycle Workflow with a custom task extension (Logic App) that fires on the joiner trigger and calls PATCH /users/{id} with the personal email sourced from a Workday attribute written to an extension attribute at provisioning time.
When to Use This Pattern vs. Alternatives
| APPROACH | TIMING | COMPLEXITY | BEST FOR |
|---|---|---|---|
| Second connector (this post) | ~80 min after account creation | Low — one additional provisioning app | Pre-hire provisioning, no Governance license |
| Lifecycle Workflow + Logic App | Minutes after account appears | Medium — requires Entra ID Governance license | Same-day onboarding, real-time enrichment |
| Workday → Entra ID cloud connector (direct) | Same cycle as account creation | Low — native mapping on cloud-only connector | Cloud-only users only — does not help hybrid |
| Graph API via PowerShell / Azure Function | On-demand / scheduled | Medium — requires code and scheduled trigger | Bulk backfill of existing accounts |
Summary
Cloud Sync's inability to write otherMails is not a blocker — it is an architectural boundary that the second connector pattern cleanly crosses. The pattern works because Entra ID provisioning connectors are general-purpose Graph API clients: they can update any writable user attribute, and they are not limited to account creation.
The three things that make this pattern safe are:
- Create: OFF — the connector cannot create orphan accounts
- Narrow attribute mapping — only
otherMailsand the match key, nothing else - Mutually exclusive scoping — hybrid workers only, mirroring Connector 1's scope exactly
Add this connector to your Workday provisioning architecture alongside the existing AD connector and Cloud Sync, and hybrid users will have their personal email populated in otherMails automatically on every provisioning cycle — no Logic Apps, no custom code, no Governance license required.
