Keka to Entra ID and Active Directory: Joinly vs Microsoft's native provisioning

What Microsoft gives you for Keka

Microsoft has no native Keka 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 Keka (the Keka REST API, oAuth 2.0 (client id, client secret and API key, scope ‘kekaapi’)), 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 Keka, and goes further on both ends.

• A ready-made Keka import plugin, reading the Keka REST API with oAuth 2.0 (client id, client secret and API key, scope ‘kekaapi’) — 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 Keka 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 Keka 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 Keka and applies the rules, and the Entra provisioning service does the write. The SCIM page for Keka describes that route.