How does Joinly sync Keka to Microsoft Entra ID?

Joinly reads each HR change in Keka through the REST API and applies it to the matching Entra ID account automatically. Keka holds the authoritative employment record, so it is the starting point for each identity action.

1. Joiner. HR completes the hire in Keka. Joinly reads the new employee record and determines the role from attributes like department, job title, legal entity and cost center. It then creates the account in Entra ID, assigns the right licences and maps the person into the correct groups — timed to the recorded joining date.

2. Mover. When someone changes department, business unit or legal entity in Keka, Joinly updates their group membership, permissions and licences to match. Access that no longer fits the new position is revoked, so permissions stay aligned with the actual job.

3. Leaver. On the Date of Exit recorded in Keka, Joinly disables the Entra ID account automatically. There are no orphaned accounts left active after someone has left, and the leaver action keys off the recorded exit date rather than the moment the record was edited.

Example: A growing IT-services company runs Keka across two legal entities and hires a support engineer with a joining date next Monday. Joinly reads the record, waits until the joining date, creates the Entra ID account, assigns a Microsoft 365 Business Premium licence and adds the engineer to the Support-Team group scoped to the right legal entity. When that engineer later transfers to the professional-services business unit, Joinly swaps the groups the same day and leaves the UPN untouched.

What manual user management costs

Without automation, every account starts as a Keka ticket or a line in a spreadsheet that IT works through by hand. Because Microsoft ships no pre-built Keka connector, the native option is Entra’s generic API-driven inbound provisioning — a bulk endpoint you have to build a script or middleware around — so the part that actually decides access still falls to people.

• Onboarding delays. New joiners wait for accounts, licences and group access while a ticket sits in a queue, losing productive days in their first week.

• Permissions that don’t keep up (privilege creep). When movers change department or legal entity, old access often stays attached, so people accumulate rights they no longer need.

• Forgotten offboarding. Accounts that aren’t disabled on time are both a security and audit risk, and unused licences keep costing money — especially when a Date of Exit is entered late or in a bulk upload.

Joinly vs. native API-driven provisioning for Keka

There is no packaged Microsoft connector for Keka, so the native path is Entra’s generic API-driven inbound provisioning — a SCIM bulk endpoint fed by a custom script or an iPaaS broker. It can move attributes, but it stops short of the part that actually decides access. Here’s how the two compare.

Watch-outs when connecting Keka to Microsoft Entra ID

A few Keka-specific details decide whether this connection stays reliable at scale.

• No native Microsoft connector. Keka isn’t in the Entra HR-driven provisioning gallery the way SuccessFactors and Workday are, so the do-it-yourself route means building and maintaining a script or iPaaS around Entra’s generic bulk endpoint. Joinly ships the Keka integration ready to use, so there is nothing custom to keep alive.

• India statutory fields. Keka records carry UAN, PF, ESI and PAN, and the UAN is portable across employers. These belong in HR and payroll, not the directory. Joinly maps only the attributes you choose and never uses a statutory identifier as an account key, so nothing sensitive leaks into Entra ID.

• Multiple legal entities and business units. One Keka subscription can span several legal entities, each with its own business units and departments. A flat rule breaks quickly. Joinly builds explicit mapping from legal entity, business unit and department to the correct Entra groups and licences.

• UPN format with duplicate names. When two employees share a name, a naive UPN rule produces collisions. Joinly applies custom transformation rules — a suffix, legal-entity code or controlled tiebreaker — so every UPN is unique and predictable from day one.

• API rate limits. The Keka API is rate-limited, so a large initial load or a big bulk change has to be paced. Joinly reads incrementally and backs off automatically, so a first sync of thousands of employees never trips the limit.

Joinly handles each of these by default with custom mapping and transformation.

Always audit-ready

Every account action Joinly performs is logged: who was affected, when it happened, which access changed and which Keka change triggered it. For NIS2 that matters directly: access can be traced back to an authorised HR source rather than an ad-hoc request. Joinly is ISO 27001 certified, runs in an EU data centre in Amsterdam, applies least-privilege by default, and is built to meet NIS2 and ISO 27001.

Example case

Picture an IT-services company with around 900 employees across two legal entities, running Keka as its HR core while account creation lags behind. There is no pre-built Keka connector for Entra ID, so a small script pushes a nightly export — but it can’t tell one legal entity from another, transfers between business units are handled by hand, and every new engineer waits for someone to set up their account and licence before they can start on a client project.

Connect Keka to Microsoft Entra ID with Joinly and that work disappears. Joinly reads each HR change in Keka at the source and acts on it automatically: new hires have their account, Microsoft 365 licence and group access ready on their joining date, transfers between business units swap the right groups the same day, statutory fields stay in payroll where they belong, and leavers are disabled on their Date of Exit with a 30-day soft-delete grace window.

“We used to keep a fragile export script alive just to get people into Entra. Now an account is simply ready on the joining date, transfers move themselves, and we can show exactly which Keka change created every bit of access.” — Head of IT, IT-services company

The outcome this setup is designed for: onboarding drops from days to zero touch, the custom export script is retired, and the team can walk into its next audit with a complete, source-backed trail.