How does Joinly sync BCS HR to Microsoft Entra ID?

Joinly reads each HR change in BCS HR through the RESTful Services API and applies it to the matching Entra ID account automatically. BCS holds the authoritative medewerker and dienstverband record, so it is the starting point for each identity action.

1. Joiner. HR completes the hire in BCS HR. Joinly reads the new medewerker and dienstverband, determines the role from attributes like afdeling, functie and kostenplaats, then creates the account in Entra ID, assigns the right licences and maps the person into the correct groups — timed to the contract start date rather than the moment the record was entered.

2. Mover. When someone changes functie, afdeling or organisatie-eenheid in BCS, Joinly updates their group membership, permissions and licences to match. Access that no longer fits the new role is revoked, so permissions stay aligned with the actual job.

3. Leaver. On the end date of the dienstverband recorded in BCS, Joinly disables the Entra ID account automatically. There are no orphaned accounts left active after someone leaves, and multiple dienstverbanden are taken into account, so access is only removed when the last active contract ends.

Example: A staffing agency hires a warehouse flex worker in BCS HR with a start date next Monday. Joinly reads the dienstverband, waits until the start date, creates the Entra ID account, assigns a lightweight licence and adds the worker to the correct client-site group. When that worker later picks up a second placement at another client, Joinly keeps one stable UPN and simply adds the extra group, so both assignments work without breaking sign-in.

What manual user management costs

Without automation, every account starts as a BCS ticket or a line in a spreadsheet that IT works through by hand. BCS can export employee data over its webservices or as a file, and you can build a custom job against the RESTful Services API, but a raw export moves attributes only — it doesn’t map roles to groups or reason about contract dates and multiple placements, 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 — painful in staffing, where a flex worker may only be on site for a few weeks.

• Permissions that don’t keep up (privilege creep). When movers change functie or afdeling, 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 multiple dienstverbanden it is easy to disable an account while another contract is still active.

Joinly vs. a custom BCS export / Entra Cloud Sync

BCS has no native provisioning to Entra ID, so the realistic alternative is a custom job on the BCS webservice or file export, or a generic attribute flow such as Entra Cloud Sync. Both move data; neither decides access. Here’s how they compare for a BCS-driven setup.

Watch-outs when connecting BCS HR to Microsoft Entra ID

A few BCS-specific and staffing-specific details decide whether this connection stays reliable at scale.

• Contract dates and high churn. In a flex or uitzend context, short dienstverbanden start and end constantly, and provisioning too early or too late both cause problems. Joinly reads the contract start and end dates and times account creation and disable to them, so access is ready on the right day and gone when the contract ends.

• Multiple dienstverbanden per person. One medewerker can hold more than one active or sequential contract — for example a worker placed at two clients. A naive rule can create a duplicate account or disable sign-in while another contract is still live. Joinly applies explicit rules to keep one stable UPN and add access per placement.

• Retroactive changes and rehires. BCS handles changes with terugwerkende kracht and frequent rehires. Joinly reconciles back-dated starts and re-activates the correct existing account on a rehire instead of spawning a new one.

• Mapping BCS structures to Entra groups. Afdeling, kostenplaats, organisatie-eenheid and functie 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, org-unit code or controlled tiebreaker — so every UPN is unique and predictable from day one.

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 BCS HR 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 active flex workers placed across dozens of client sites, running BCS HR for its personnel and payroll administration while its identity provisioning never quite keeps up. New placements start and end every week, workers often hold two dienstverbanden at once, and rehires are routine — so the IT team keys accounts by hand from a BCS export. New flex workers wait until day two or three for a login, and every so often an account is disabled while the person is still working a second placement.

Connect BCS HR to Microsoft Entra ID with Joinly and that work disappears. Joinly reads each HR change in BCS at the source and acts on it automatically: new placements have their account, licence and group access ready on the contract start date, a second placement just adds access under one stable UPN, transfers swap the right groups the same day, and leavers are disabled on the contract end date with a 30-day soft-delete grace window.

“Multiple contracts and constant rehires used to break every manual step. Now an account is simply ready on the start date, a second placement just adds access, and we can show exactly which BCS change created every bit of access.” — Head of IT, staffing agency

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