You're migrating from Okta to Entra ID and you've hit the provisioning gap that stops most migrations cold: Okta lets you map specific attributes, permission sets, and license tiers to users based on group membership, and Entra ID's native SCIM engine doesn't support that in the same way. A user in gg-salesforce-marketing gets Salesforce Permission Set X; a user in gg-salesforce-readonly gets a different license tier. In Okta, those rules are configured directly in the SCIM provisioning framework. In Entra ID, the path to the same outcome requires a different architectural approach.

What Okta Does That Entra ID Native SCIM Doesn't

The gap is specific and worth naming precisely, because the workarounds depend on understanding exactly what's different.

In Okta, group membership is a first-class input to SCIM provisioning. You can configure attribute mappings that evaluate which groups a user belongs to and derive provisioned values from that membership — assigning Salesforce Permission Set X if the user is in Group A, assigning License Tier Y if the user is in Group B. The provisioning cycle reads group membership as a dynamic input, evaluates the rules, and sends the appropriate attribute values in the SCIM payload to the target application.

In Entra ID, SCIM provisioning supports attribute mapping from user attributes — department, job title, extension attributes, and others — but not from group membership evaluation at the time the SCIM payload is constructed. The provisioning engine doesn't evaluate which groups a user belongs to and derive attribute values from that membership in the same way Okta does. One commenter in the thread confirmed this is a real gap: emitting different attributes depending on group membership isn't supported in Entra's native SCIM, and the architectural reason is that it would be performance-intensive at scale.

The thread also surfaced a fundamental framing that clarifies the migration decision: Okta is an IGA/IAM layer with IdP capabilities built in. Entra ID is an IdP with IGA/IAM capabilities available as a separately licensed add-on (Entra ID Governance). The provisioning sophistication in Okta reflects the IGA layer, not the IdP layer. To get comparable functionality in a Microsoft environment, you need either Entra ID Governance (which several commenters noted could consume the cost savings from leaving Okta) or an IGA platform that sits above Entra ID.

What Entra ID Does Offer (And Where Each Approach Has Limits)

The thread surfaced several native Entra ID paths worth working through before reaching for custom code or a third-party platform.

App roles via app registration. You can create app roles under the app registration for each target application, assign app roles to the groups assigned to the enterprise app, and map those roles through in the SCIM payload. This handles role assignment based on group membership through Entra's app role framework. The limitation the OP identified: app role assignment covers roles, but not permission sets, license tiers, or other granular entitlements that exist as distinct attributes in the target application.

Group-based licensing. Entra ID natively supports assigning M365 licenses to security groups, with group members receiving the license automatically. This covers the license assignment use case within the Microsoft ecosystem. It doesn't extend to license assignment within third-party SaaS applications (Salesforce license tiers, ServiceNow roles) via SCIM.

Dynamic group membership with user attribute pre-enrichment. One commenter suggested an event-driven architecture: when a user is added to a security group, an automation (Azure Automation runbook was the specific suggestion) updates the user's Entra ID object attributes (standard attributes or extension attributes 1–15) to reflect their entitlements, and the SCIM config for each target application maps those attributes to the corresponding app-side values. This replicates the Okta behavior using a different mechanism — group membership drives attribute enrichment at the Entra ID user object level, and SCIM provisioning sends those enriched attributes downstream.

The operational overhead of this approach is significant: each security group addition triggers an automation that updates user attributes, and each target application needs SCIM attribute mapping configured to read those enriched attributes. For a small number of applications and group rules, it's manageable. For a complex provisioning environment with many applications and many group-to-attribute mappings — the kind of environment that relied heavily on Okta's group-based provisioning — it becomes the custom SCIM middleware complexity the OP was trying to avoid.

SAML claims-based authorization. For applications that support it, emitting group membership as a SAML claim during SSO lets the application handle authorization internally based on the claim value. This separates provisioning (what account exists) from authorization (what the account can access). It works for applications that support claims-based authorization; it doesn't work for applications where the permission set or license assignment happens at the identity provider level through SCIM.

Entra ID Governance — Access Packages. Access packages allow you to bundle multiple resource assignments (application roles, group memberships, SharePoint sites) into a single requestable or auto-assignable package. When a user meets the conditions for an access package, all the bundled assignments are applied. This is probably the closest native analog to Okta's group-to-entitlement mapping, but it requires Entra ID Governance licensing — which, as one commenter noted, may consume the savings from leaving Okta.

The Custom Middleware Path and Why It Compounds Over Time

The OP's fallback — custom SCIM payload enrichment logic via Microsoft Graph API — is technically viable but has a specific maintenance profile worth understanding before committing to it.

The Graph API reads group membership, the middleware constructs the enriched SCIM payload, and the payload delivers the granular attribute values to the target application. It works. The problems emerge over time:

Every new application that needs group-based attribute provisioning requires a new set of mapping rules in the middleware. Every change to the group structure (new groups added, groups renamed, entitlement rules modified) requires updating the middleware logic. When the Graph API changes, the middleware may break silently. When a SaaS application updates its SCIM schema, the payload construction may fail. The team member who built the middleware becomes the single point of knowledge for the system, replicating the developer-dependency problem that shows up in every custom provisioning build discussion.

One commenter who confirmed the same gap in their Okta-to-Entra migration noted their plan: migrate Okta login authentication to Entra first, then migrate applications one at a time, keeping Okta active until each application is fully migrated. This phased approach avoids rebuilding the entire provisioning architecture at once, but it extends the period of dual-IdP complexity.

How an IGA Orchestration Layer Solves the Group-to-Attribute Mapping Problem

The reason Okta's group-based provisioning works elegantly is that Okta is operating as an IGA layer, not just an IdP. The provisioning rules, the attribute mapping flexibility, the group-based entitlement logic — these are IGA capabilities. Replicating them in an Entra ID environment without an IGA layer requires custom code because you're asking the IdP (Entra ID) to do IGA work it wasn't designed to handle natively.

Zluri sits as the IGA orchestration layer above Entra ID, adding the provisioning logic that native Entra ID SCIM doesn't provide. The architecture: Entra ID handles identity, SSO, and directory. Zluri monitors Entra ID group membership and responds to changes with targeted provisioning actions.

When a user is added to a specific Entra ID group — gg-salesforce-marketing, for example — Zluri detects the event and triggers a provisioning playbook configured for that group. The playbook executes direct API calls to Salesforce, assigning the specific permission set and license tier configured for that group without relying on SCIM attribute mapping to carry the values. When a user is added to gg-salesforce-readonly, a different automation triggers a playbook that provisions the read-only license tier and the corresponding permission set.

For applications where the SCIM attribute mapping approach is sufficient but needs to be extended with group-derived values, Zluri's HTTP request actions can construct and send custom API payloads that include the group-derived attribute values — without requiring a separately maintained middleware service. The logic lives in the playbook configuration rather than in custom code.

For license assignment specifically, Zluri supports group-based license assignment natively: Entra ID groups are mapped to license configurations within Zluri, and all members of the group receive the configured license in the target application automatically.

Frequently Asked Questions

Can Entra ID do group-based attribute provisioning like Okta?

Not natively in the same way. Entra ID's SCIM provisioning engine maps user attributes to downstream app attributes but doesn't evaluate group membership at payload construction time to derive attribute values. Workarounds include app roles (for role assignment), event-driven user attribute enrichment via Azure Automation (for custom attribute mapping), SAML claims for authorization in supported apps, and Entra ID Governance Access Packages for bundled entitlement assignment.

What is the Entra ID equivalent of Okta's group-to-permission-set mapping?

The closest native equivalent for complex scenarios is Entra ID Governance Access Packages, which bundle multiple resource assignments into a single assignable unit. For simpler scenarios, app roles assigned to groups and mapped through SCIM handle role assignment. Neither approach covers the full range of Okta's group-based attribute provisioning without additional configuration or licensing.

How do you provision Salesforce permission sets and license tiers from Entra ID group membership?

Options include: Entra ID Governance Access Packages (separately licensed); event-driven user attribute enrichment with SCIM mapping; or an IGA platform like Zluri that triggers direct Salesforce API calls when users are added to specific Entra ID groups, assigning the exact permission set and license tier without relying on SCIM attribute mapping.

Is Entra ID Governance worth the additional licensing cost for Okta migrations?

It depends on how extensively you relied on Okta's group-based provisioning. If your migration involves many applications with complex group-to-entitlement mappings, Entra ID Governance may be necessary — but the licensing cost partially offsets the savings from leaving Okta. An IGA platform that operates above Entra ID handles the same provisioning complexity without requiring Entra ID Governance for each feature.

What is the difference between Entra ID as an IdP and Okta as an IGA layer?

Entra ID is primarily an identity provider with identity governance features available as a licensed add-on. Okta operates as both an IdP and an IGA/IAM layer, with provisioning sophistication (group-based attribute mapping, push groups, granular entitlement rules) built into the core product rather than licensed separately. This architectural difference explains why direct feature-for-feature comparison of provisioning capabilities is misleading — the IGA functionality in Okta corresponds to Entra ID Governance, not to Entra ID core.

See How Zluri Handles Group-Based Attribute Provisioning Above Entra ID

Most Okta-to-Entra migrations hit the group-based provisioning gap and either pay for Entra ID Governance or build custom middleware. See how Zluri's event-driven playbooks replicate Okta's group-to-attribute provisioning logic above Entra ID — without custom code or additional Microsoft licensing.