How does Joinly sync isolved to Microsoft Entra ID?

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

1. Joiner. HR or the service bureau completes the hire in isolved. Joinly reads the new employee record and determines the role from attributes like legal company, department, job and work location. It then creates the account in Entra ID, assigns the right licences and maps the person into the correct groups — timed to the isolved hire date.

2. Mover. When someone changes department, job, work location or legal company in isolved, 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. When the isolved employee status moves to Terminated on the recorded termination date, Joinly disables the Entra ID account automatically. There are no orphaned accounts left active after someone has left, and a rehire or status reversal is recognised rather than creating a second account.

Example: A staffing agency hires a recruiter in isolved with a start date next Monday, in its East-region legal company. Joinly reads the hire record, waits until the start date, creates the Entra ID account, assigns an Office E3 licence and adds the recruiter to the East-Recruiting group. When that recruiter later transfers to a second legal company in the same isolved client, Joinly reads it as one person moving FEINs, keeps the same UPN and swaps the regional group instead of spinning up a duplicate account.

What manual user management costs

Without automation, every account starts as an isolved request or a line in a spreadsheet that IT works through by hand. isolved Marketplace IGA connectors and SCIM/IdP integrations like Okta or OneLogin can move attributes across, but they map roles to groups through manual rules and don’t reason about multi-company clients or pay-driven status changes — so the part that actually decides access still falls to people.

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

• Permissions that don’t keep up (privilege creep). When movers change department, job or legal company, 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 — and with payroll-driven statuses a Terminated flag can flip back on a rehire or pay correction, so timing matters.

Joinly vs. isolved Marketplace connectors

isolved Marketplace IGA partners and SCIM connectors are a fine baseline, but they stop short of the part that actually decides access. Here’s how the two compare for an isolved People Cloud-driven setup.

Watch-outs when connecting isolved to Microsoft Entra ID

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

• Multi-company clients. One isolved client can hold several legal companies (FEINs), and employees move between them. A naive rule reads that move as a termination in one company and a new hire in another, producing a duplicate account. Joinly recognises the same person across legal companies and treats it as a single transfer.

• Payroll-driven dates and statuses. Hire and termination dates in isolved are pay-driven, and a Terminated status can reverse on a rehire or a pay correction. Joinly reads the effective status and date, so it disables on the real termination date and reactivates cleanly on a rehire rather than orphaning an account.

• Mapping legal company and department to Entra groups. Legal company, department, job and work location don’t translate one-to-one to Entra ID groups. Joinly builds explicit mapping rules from those structures to the correct groups and licences, so role drives access rather than manual assignment.

• 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-company code or controlled tiebreaker — so every UPN is unique and predictable from day one.

• Partner-mediated API access. isolved API access runs through a registered API Application and, often, a service bureau or Marketplace partner relationship. Joinly works with the OAuth Client ID and secret you provision, and only requests the scopes needed to read the employee data it maps.

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 isolved 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 a staffing agency with around 3,500 internal and placed employees, running isolved People Cloud across several legal companies while its identity provisioning never quite keeps up. A marketplace SCIM connector handles the simple cases, yet seasonal contracts, recruiters moving between regional legal companies and a steady stream of rehires keep breaking it — a transfer between FEINs ends up as a terminated account plus a fresh duplicate, and new placements are provisioned the moment payroll saves the record rather than on their actual start date.

Connect isolved to Microsoft Entra ID with Joinly and that work disappears. Joinly reads each HR change in isolved at the source and acts on it automatically: new joiners have their account, Office licence and group access ready on their hire date, moves between legal companies swap the right groups on a single identity the same day, rehires reactivate the existing account, and leavers are disabled on their termination date with a 30-day soft-delete grace window.

“Moving recruiters between legal companies used to create a duplicate account every time. Now an account is simply ready on the start date, a transfer just swaps the groups, and we can show the auditor exactly which isolved change created every bit of access.” — Head of IT, national staffing agency

The outcome this setup is designed for: onboarding drops from days to zero touch, duplicate-account errors from legal-company moves stop entirely, and the team can walk into its next NIS2 assessment with a complete, source-backed audit trail.