How does Joinly sync Deel to Active Directory?

Joinly reads each HR change in Deel in the cloud, then hands the action to the Joinly AD Agent inside your network, which makes the change in Active Directory. Deel holds the authoritative worker record — including the worker type, legal entity and group — while the agent is the only component that touches your domain.

1. Joiner. HR completes the hire in Deel — an EOR contract, a global-payroll direct employee or a contractor agreement. Joinly reads the new record, determines the role from worker type, group, legal entity and location, and instructs the AD Agent to create the user in the correct OU, build the sAMAccountName and UPN from your rules, and add the right security groups — with a different OU and group set for a contractor than for a full employee.

2. Mover. When someone changes group or location, or is converted from contractor to EOR employee, Joinly tells the agent to move the user to the matching OU, swap security-group membership and update attributes. Access that no longer fits the new situation is removed, so permissions stay aligned with the actual engagement.

3. Leaver. On the end date recorded in Deel, Joinly instructs the agent to disable the AD account and optionally move it to a disabled-users OU. Each worker’s own local end date drives the timing, so an EOR contract in one country and a contractor agreement in another are each retired on their own day.

Example: A global design studio runs Deel and an on-premise AD across three offices. It hires a motion designer as an EOR employee with a start date next Monday and renews a freelance illustrator as a contractor. Joinly reads each Deel record, and on Monday the AD Agent creates the designer in the Studio > Design OU with the Design-Team group, while the contractor lands in a separate Contractors OU with a restricted group set. When the illustrator is later converted to a direct employee, the agent moves the object to the employee OU and swaps the groups the same day.

What manual AD account management costs

Without automation, every account starts as a Deel notification that an admin works through in Active Directory Users and Computers by hand — creating the object, choosing the OU, building the sAMAccountName, adding groups. Deel’s own SCIM and native integrations only reach cloud IdPs, not your on-premise AD, and they carry no group or worker-type logic, so every AD decision falls to people.

• Onboarding delays. New joiners wait for an AD account and group access while a ticket sits in a queue, losing productive days in their first week — and with a distributed team the request often arrives in a different time zone than the admin.

• Permissions that don’t keep up (privilege creep). When movers change group or convert from contractor to employee, old security-group membership often stays attached, so people accumulate rights they no longer need.

• Forgotten offboarding. Accounts that aren’t disabled on time are a security and audit risk — and with contractors and EOR contracts ending on many different local dates, it is easy to miss one.

Joinly vs. the Entra provisioning agent for AD

Deel’s own SCIM reaches only cloud IdPs, so provisioning Deel to on-premise AD usually means chaining Deel SCIM into Entra ID and out through Microsoft’s Entra provisioning agent. Here’s how that native path compares to the Joinly AD Agent for a Deel-driven AD setup.

Watch-outs when connecting Deel to Active Directory

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

• sAMAccountName uniqueness and length. AD limits the sAMAccountName to 20 characters and it must be unique across the domain. Joinly builds it from your rules with a fallback pattern, so duplicate names across countries never produce a collision or a truncated, unreadable login.

• Mixed worker types and OU placement. A single Deel org holds EOR employees, direct payroll employees and contractors. They should not share an OU or a group set — a contractor often belongs in a separate, restricted OU. Joinly reads the worker type and places each user in the right OU, moving them when the type changes.

• EOR vs direct employment. For an EOR worker, Deel’s own entity is the legal employer while the person works for your company. Joinly maps OUs and groups from your organisation’s group and location, not the Deel EOR entity, so a naive entity-to-OU rule doesn’t put people in the wrong place.

• Multi-country and multi-entity timing. Workers span many legal entities and countries, each with its own start and end date. Joinly has the agent create or disable each account on that worker’s own local date rather than in one global batch.

• Service-account permissions. The agent acts under a service account with delegated rights. Joinly works with least-privilege delegation scoped to the target OUs, so the agent can create, move and disable users without domain-admin rights.

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

Always audit-ready

Every account action the Joinly AD Agent performs is logged in the Joinly cloud: who was affected, when it happened, which OU and groups changed and which Deel 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

Take a global design and product studio with around 700 people across six offices, running Deel for a mix of EOR employees and a rotating roster of freelance contractors, but still living in an on-premise Active Directory for its production and asset systems. Every new hire — whether an EOR designer or a freelance illustrator — starts as a Deel notification that IT processes by hand in AD, and freelancers too often end up in the same OUs and groups as full employees because there is no logic to tell them apart.

Connect Deel to Active Directory with Joinly and that work disappears. The Joinly AD Agent creates each EOR and payroll employee in the right OU on their local start date, builds a unique sAMAccountName, adds the correct security groups, and drops contractors into a separate restricted OU — then moves people on a transfer or worker-type change and disables accounts on the end date with a 30-day grace window, all driven by the HR change in Deel.

“Freelancers used to land in the same OU as staff and inherit access they never should have had. Now Joinly reads the Deel worker type and puts contractors in their own restricted OU on day one — and every account is ready the moment they start.” — Head of IT, global design and product studio

The outcome this setup is designed for: onboarding drops from days to zero touch, contractors and employees stay cleanly separated in AD, and the team can walk into its next NIS2 assessment with a complete, source-backed audit trail.