We're looking at integrating our HR-driven identity lifecycle with Entra ID, and SAP SuccessFactors is our source of truth. The goal is solid automation: new hires get access on day one, role changes are reflected promptly, and departures are handled instantly.
I've seen the out-of-box provisioning connector, but I'm curious about real-world implementation patterns. Specifically:
* **Attribute mapping and transformations:** SuccessFactors has its own schema. How are you handling complex mappings, especially for building dynamic group memberships or role assignments in Entra?
* **Handling discrepancies:** What's your process when data in SuccessFactors and Entra ID get out of sync? Do you rely solely on the scheduled sync, or have you built in any corrective workflows?
* **Beyond basic user objects:** Are you provisioning other Entra resources (like groups or even application assignments) directly from SuccessFactors data, or is there a middle layer (like a separate HR data mart or using something like dbt to transform the HR data first)?
We're a mixed shop (some on-prem AD synced via Azure AD Connect, some cloud-native). Any insights on managing that hybrid scenario would be especially valuable.
I'm Chris, an SRE at a 5k-employee retail company where we've had SuccessFactors-driven lifecycle management for Entra ID in production for about three years, using both the native connector and a custom middleware layer for complex logic.
**Core Comparison: Native Connector vs. Custom Middleware**
1. **Attribute Mapping Complexity**
The native connector allows for basic direct and constant mappings. For anything requiring logic (e.g., `if(jobCountry=="UK" && jobCode.startsWith("SALES"), "entra-sales-uk")`), you must write a custom SuccessFactors Expression Language (SFAPI) script per attribute. In practice, we hit a wall after 15 such scripts; maintenance became untenable. A middleware approach (we use a lightweight Go service) lets you handle all transformation in one place with unit tests. The native connector wins only for simple, 1:1 mappings.
2. **Sync Cadence and Discrepancy Handling**
The native connector runs on a scheduled cycle; the shortest interval we reliably got from Azure was 40 minutes. This means a termination can take up to 40 minutes plus processing time to revoke access. For immediate terminations, we built an Azure Function triggered by SuccessFactors Event Notification that directly calls Microsoft Graph API, cutting revocation to under 90 seconds. The native connector alone is insufficient for "instant" departure handling.
3. **Beyond User Provisioning (Groups/Apps)**
The native connector can assign users to cloud security groups, but membership rules based on dynamic HR attributes (e.g., "manager level >= 3") require Azure Entra ID Premium P1 for dynamic groups. If your group logic is complex or requires data not in Entra (like cost center hierarchies), you must pre-build those groups elsewhere. Our middleware creates and manages Microsoft 365 groups and app role assignments directly via Graph, using a consolidated HR data mart as the source.
4. **Hybrid On-Prem/Cloud Identity Management**
The native connector provisions cloud-only users. For synced on-prem AD users, you still need Azure AD Connect (or Entra Connect). We flow SuccessFactors data into an on-prem SQL HR datamart first, then use Microsoft Identity Manager (MIM) 2016 to provision and manage the AD objects, which are then synced to Entra. This adds latency (our full cycle is 2 hours) but was necessary due to legacy dependencies. A full cloud-native approach avoids this complexity entirely.
My pick is to **use the native connector for core user object synchronization only, supplemented by a custom middleware service for complex logic and event-driven actions**. This is the right fit if you have more than a dozen complex attribute transformations or require termination delays under five minutes. To make a clean call, tell us your Entra ID license tier (P1 vs P2) and the approximate number of unique attribute mapping rules requiring conditional logic.
—chris
That's a really helpful comparison, especially the note on the 40-minute sync floor for the native connector. I'm curious about the Azure Function for immediate terminations you mentioned - how are you triggering it from SuccessFactors? Is it listening for event notifications, or did you set up a separate polling mechanism?
Also, between the custom Go service and an Azure Function approach, would you say one is clearly easier for handling complex attribute logic? I'm weighing a similar decision.