How does Joinly sync Remote to Active Directory?

Joinly reads each employment change in Remote in the cloud through the Remote API, then hands the action to the Joinly AD Agent inside your network, which makes the change in Active Directory. Remote holds the authoritative employment record; the agent is the only component that touches your domain.

1. Joiner. HR completes the hire in Remote and the employment moves to an active status. Joinly reads the record, determines the role from job title, department, country and legal entity, checks the employment_type, 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 — timed to the start of active employment.

2. Mover. When someone changes job title, department, country or legal entity in Remote — or converts from contractor to 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 position is removed, so permissions stay aligned with the actual role.

3. Leaver. When a Remote employment reaches its termination_date and moves to ‘archived’, Joinly instructs the agent to disable the AD account and optionally move it to a disabled-users OU. Because a person can hold more than one engagement, an account is only disabled when their last active employment ends.

Example: An international NGO runs Remote and an on-premise AD across its country offices. It hires a programme coordinator in Kenya as an EOR employee with a start date next Monday. Joinly reads the Remote employment, and when it goes active the AD Agent creates the user in the KE-Programmes OU, sets a unique sAMAccountName, and adds the Field-Staff group. When a short-term consultant is later engaged as a contractor, the agent places that account in a separate Contractors OU with a limited group set instead of full staff access.

What manual AD account management costs

Without automation, every account starts as a note from HR that an admin works through in Active Directory Users and Computers by hand — creating the object, choosing the OU, building the sAMAccountName, adding groups. You can export from Remote or script against its API, but that leaves the decisions — which worker type, which country’s OU, which groups — to people, and it drifts the moment the workforce changes.

• Onboarding delays. New joiners wait for an AD account and group access while a request sits in a queue, losing productive days in their first week — and a cross-border EOR hire is exactly the kind that gets missed.

• Permissions that don’t keep up (privilege creep). When movers change role or country, 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 — easy to miss when an offboarding in Remote is just one archived employment among many countries.

Joinly vs. a scripted Remote-to-AD integration

Remote’s own integrations point inward, toward HRIS and finance tools, and it doesn’t ship an on-premise AD provisioning connector. So the realistic alternative is a home-grown script that pulls the Remote API and runs PowerShell against your domain. Here’s how the two compare for an on-premise AD setup.

Watch-outs when connecting Remote to Active Directory

A few Remote-specific details decide whether this connection stays reliable across countries and worker types.

• sAMAccountName uniqueness and length. AD limits the sAMAccountName to 20 characters and it must be unique across the domain — a real risk with a large, multi-country workforce full of similar names. Joinly builds it from your rules with a fallback pattern, so duplicate names never produce a collision or a truncated, unreadable login.

• OU placement from legal entity and worker type. Remote’s countries, legal entities and worker types don’t map one-to-one to your OU structure, and an EOR employee, a direct employee and a contractor shouldn’t share an OU. Joinly builds explicit rules that place each user — and move them on a transfer or conversion — into the correct OU.

• Mixed worker types in one tenant. EOR employees, direct-payroll employees and contractors all live under the same Remote company. Joinly reads employment_type so a contractor gets a limited AD profile and its own groups rather than full staff access.

• Employment lifecycle timing. A Remote hire passes through ‘created’ and ‘invited’ before it becomes ‘active’, and flips to ‘archived’ on the termination_date. Joinly has the agent create the account when employment goes active and disable it when it is archived, not before.

• 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 Remote 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 an international NGO with around 1,800 staff across a dozen country offices, running Remote for its EOR employees and contractors but still living in an on-premise Active Directory for its case-management and file systems. Every new field worker, coordinator or short-term consultant starts as a note from HR that IT processes by hand in AD — creating the object, picking the country OU, building the login, adding groups. With rotating programme staff and frequent transfers between offices, the queue never empties, and new joiners in a new country wait days for access.

Connect Remote to Active Directory with Joinly and that work disappears. The Joinly AD Agent creates each user in the right country OU when their employment goes active, builds a unique sAMAccountName, adds the correct security groups, keeps contractors in a separate OU with limited access, moves people on a transfer, and disables accounts when the employment is archived on the termination date — all driven by the change in Remote.

“We hire in countries where we’ve never run IT before, and the old manual routine couldn’t keep up. Now a coordinator in Kenya has an account in the right OU on day one, a consultant never lands in the staff groups by accident, and we can show the auditor exactly which Remote change created every account.” — Head of IT, international NGO

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