Oracle EBS HR to Entra ID and Active Directory: Joinly vs Microsoft's native provisioning

What Microsoft gives you for Oracle EBS HR

Microsoft has no native Oracle EBS HR connector. What it offers is API-driven inbound provisioning: a provisioning app with a /bulkUpload endpoint that accepts SCIM 2.0 bulk requests from "any system of record". The catch is in Microsoft's own description of the flow — "the API developer/partner/system integrator builds an API client to send authoritative identity data to Microsoft Entra ID". Someone has to build and run the client that reads Oracle EBS HR (the EBS HRMS public APIs / effective-dated extract), packages every record as SCIM, watches the provisioning logs and resubmits what failed. Microsoft's tutorials use PowerShell or Azure Logic Apps for it. The feature needs Microsoft Entra ID P1, P2 or Governance.

What Joinly adds

Joinly starts where the Microsoft route starts, at Oracle EBS HR, and goes further on both ends.

• A ready-made Oracle EBS HR import plugin, reading the EBS HRMS public APIs / effective-dated extract — no client to build or host.
• The rules: which department, job, location or legal entity maps to which groups, licences and organisational unit. Microsoft's mappings move attributes; Joinly's rules decide access, and record the reason per assignment.
• Both directories from one source: Entra ID through Microsoft Graph, on-premise Active Directory through the Joinly AD Agent (outbound only, no provisioning agent to install and no inbound rules), so hybrid organisations do not run two pipelines.
• A brake: a dry run with an Excel export, thresholds per run, read-only mode, and a hard stop when an evaluation would revoke more than 20% of assignments at once.
• Beyond the directory: shared mailbox, out-of-office, SharePoint and Teams, a ticket in TOPdesk or Freshservice, an SMS with the first-day credentials, a webhook to any application — as steps in the same workflow.
• An audit log per mutation with its source and the workflow that caused it, which is the evidence an ISO 27001 or NIS2 auditor asks for.

Side by side

When Microsoft's route is enough

If you have the engineering capacity to build and maintain the Oracle EBS HR client, Entra ID is your only target and Lifecycle Workflows covers your joiner and leaver tasks, the API-driven route is a legitimate choice. Budget for the operations side: provisioning logs, throttling, failed records, and the day the Oracle EBS HR API changes.

When you want Joinly

When there is an on-premise Active Directory next to Entra ID. When the answer to "why does this person have this group" has to come from a rule, not a memory. When you want to see what a run would do before it does it. When offboarding has to reach the mailbox, SharePoint and the service desk, not just the account. And when an auditor will ask for the log.

Can I use both?

Yes. Joinly can deliver its result to Microsoft's API-driven provisioning endpoint as SCIM 2.0 bulk requests — to Entra ID or, through the provisioning agent, to Active Directory. Then Joinly reads Oracle EBS HR and applies the rules, and the Entra provisioning service does the write. The SCIM page for Oracle EBS HR describes that route.