Provisioning in Entra ID: how do employees end up in the right systems automatically?

This is the familiar hybrid situation: the account exists on premises and also needs to be available in Microsoft 365.

In a hybrid environment AD is where the account is created, and the sync brings it to the cloud. Entra Connect Sync runs every 30 minutes by default, Entra Cloud Sync every two minutes. A synchronised account has AD as its source, so you make changes there.

The sync does not create accounts based on HR, and neither of the two creates users in AD from the cloud. Cloud Sync can, however, provision groups from Entra ID to AD. The differences between the two, soft and hard match, and moving the source of authority are covered in Entra Connect or Cloud Sync.

Here the process starts with the employee, not with a manual request to IT.

Inbound provisioning reverses the direction: the HR system is the source, and the provisioning service creates the account, updates it and disables it. There are two variants.

• The ready-made apps for Workday and SuccessFactors. Microsoft fetches the data itself, both to Entra ID and to on-premises AD.
• API-driven inbound provisioning for any other system of record: another HR package, a payroll system, a CSV export or a SQL table. You (or a vendor) send the data as a SCIM bulk request to a bulkUpload endpoint, and the provisioning service does the comparison and the change. How that works, what the limits are and what you have to build yourself is covered in API-driven inbound provisioning.

If the account needs to be in on-premises AD, you install the Microsoft Entra provisioning agent on a Windows server in your network. The provisioning service gives the instruction, the agent carries it out in AD, and the sync you already have then brings the account to Entra ID. Cloud-only accounts need no agent.

An account in Entra ID is only the beginning if someone also needs to be able to work in other systems.

Outbound provisioning passes accounts from Entra ID on to the applications you use. Many apps have a connector in the enterprise apps gallery; if an app has its own SCIM 2.0 endpoint, you can connect it yourself. What SCIM is and how it works, you can read in understanding SCIM.

1. 1Open the app in the Entra admin center under Enterprise apps and choose Provisioning. Set the mode to Automatic and enter the tenant URL and the app's token.
2. 2Set the scope. Usually that is Sync only assigned users and groups: only those assigned to the app get an account. Assigning groups requires P1 or higher.
3. 3Check the attribute mappings and the matching attribute Entra ID uses to recognise an existing account in the app.
4. 4Enter a notification address, test with Provision on demand for a few users and start the provisioning.

• Nested groups do not count. The provisioning service only reads the direct members of an assigned group.
• Out of scope means disabled. If you remove someone from the group attached to the app, the service disables the account in the app. That applies to dynamic groups too: one wrong field and someone loses their access.
• After the first cycle the service runs incremental cycles that only process the changes since the previous one. The interval differs per app.
• Quarantine: if almost all calls fail, for example because of an expired token, the connection goes into quarantine. The service then tries less and less often, down to once a day, and disables the connection after four weeks.

For on-premises applications without SCIM, Microsoft uses the same provisioning agent, with connectors for LDAP, SQL, REST or SOAP and PowerShell. You need P1 for that.

Some steps take more than creating an account, for example approvals or a task on the first working day.

Provisioning creates the account. What needs to happen after that, you arrange with Lifecycle Workflows: workflows for joiners, movers and leavers that start on a date or a change. They schedule on employeeHireDate and employeeLeaveDateTime, and the tenant processes them on a schedule that runs every three hours by default. You can create up to 50 workflows.

Entitlement management is about access in packages: an access package bundles groups, apps and SharePoint sites, with an approval and an end date. With an auto-assignment policy, everyone who meets a rule gets the package automatically. Lifecycle Workflows need an Entra ID Governance licence, and the automatic assignment of access packages is also part of Governance.

If you want to know how this compares with a platform that works from HR, the comparison is on Joinly alongside Microsoft Entra ID Governance.

All routes that go through the provisioning service write to the provisioning logs: Entra ID, Enterprise apps, Provisioning logs. There you see per user what was read, compared and written, and why something failed. Changes to the configuration itself, such as a new mapping or a stopped connection, are in the audit logs.

Connect-MgGraph -Scopes "AuditLog.Read.All"

$sinds = (Get-Date).AddDays(-1).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogProvisioning -Filter "activityDateTime ge $sinds" -All |
  Where-Object { $_.ProvisioningStatusInfo.Status -eq "failure" } |
  Select-Object ActivityDateTime, ProvisioningAction,
    @{ n = "Wie";  e = { $_.SourceIdentity.DisplayName } },
    @{ n = "Fout"; e = { $_.ProvisioningStatusInfo.ErrorInformation.Reason } }

Microsoft offers powerful building blocks. But someone still has to decide which data leads, which roles belong with it and what needs to happen when something changes.

Microsoft provides the transport: from AD to the cloud, from HR to Entra ID, from Entra ID to the apps. What goes in comes from the source. A sync copies what is in AD, even if it is wrong. An inbound connection creates the account HR supplies, with the department HR filled in. An outbound connection gives access to whoever is in the group. Lifecycle Workflows start on a date that someone has to fill in.

That is why good provisioning starts with the question of where the data comes from, and who decides what belongs with a role. How to set up those groups, you can read in setting up Entra ID groups for role-based access. Which fields drive everything is covered in user attributes in Entra ID.