How does Joinly sync Nmbrs to Active Directory?

Joinly reads each HR change in Nmbrs in the cloud through the REST API, then hands the action to the Joinly AD Agent inside your network, which makes the change in Active Directory. Nmbrs holds the authoritative employment record — the service interval, department and function; the agent is the only component that touches your domain.

1. Joiner. The salary administrator completes the hire in Nmbrs. Joinly reads the new employee and their service interval, determines the role from the company, department and function, 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 service-interval start date.

2. Mover. When someone changes department, function or company in Nmbrs, Joinly tells the agent to move the user to the matching OU, swap security-group membership and update attributes. Because Nmbrs data is period-based, the change is applied in the period it takes effect, and access that no longer fits the new role is removed.

3. Leaver. When the service interval is closed with an end date in Nmbrs, Joinly instructs the agent to disable the AD account and optionally move it to a disabled-users OU. Where a person holds more than one service interval, the account is only disabled when the last active interval ends.

Example: A wholesale and trade business runs Nmbrs and an on-premise AD across two branches and a warehouse. It hires a sales-desk employee with a service-interval start date next Monday. Joinly reads the record, and on Monday morning the AD Agent creates the user in the Branch-A > Sales OU, sets a unique sAMAccountName built from the name fields, and adds the Sales-Desk group. When that person later moves to purchasing, the agent moves the object to the new OU and swaps the groups the same day.

What manual AD account management costs

Without automation, every account starts as a message from the payroll administrator that an admin works through in Active Directory Users and Computers by hand — creating the object, choosing the OU, inventing a sAMAccountName because Nmbrs holds no work email, adding groups. A hand-built Nmbrs API integration offers limited mapping, no role-to-group logic and no service-interval timing, so the decisions still fall to people.

• 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.

• Permissions that don’t keep up (privilege creep). When movers change department or function, 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 a service interval closed in payroll is easy to miss without a direct link to IT.

Joinly vs. a hand-built Nmbrs-to-AD integration

Because Nmbrs isn’t published as a native Entra ID provisioning app, writing its data into on-premise AD usually means a custom REST integration or a script. Both can push data, but they stop short of the part that actually decides access. Here’s how the two compare for a Nmbrs-driven AD setup.

Watch-outs when connecting Nmbrs to Active Directory

A few 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 — and because Nmbrs holds no work email, it has to be generated from the name fields. 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 departments and functions. A debtor’s departments and functions don’t map one-to-one to your OU structure. Joinly builds explicit rules that place each user — and move them on a transfer — into the correct OU.

• Service-interval (dienstverband) start date. In Nmbrs the service-interval start date is what payroll uses, and it isn’t always the calendar date the record was entered. Joinly reads the service-interval start date and has the agent create the account on the right day, not before.

• Period-based moves and multiple service intervals. Department and function changes are stored per period, and an employee can hold more than one service interval, including a rehire. Joinly keeps a single, stable AD object driven by the active interval, so a move or rehire updates the right object rather than creating a duplicate.

• 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 Nmbrs 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 wholesale and trade SMB with around 320 employees across two branches and a central warehouse, running Nmbrs for HR and payroll but still living in an on-premise Active Directory for its ERP and warehouse systems. Every new sales-desk hire, warehouse worker or buyer starts as a message from the payroll administrator that IT processes by hand in AD — creating the object, choosing the OU, inventing a login because Nmbrs holds no email, adding groups. With seasonal peaks and frequent moves between branches the queue never empties, and new joiners wait until day two or three for their account.

Connect Nmbrs to Active Directory with Joinly and that work disappears. The Joinly AD Agent creates each user in the right OU on the service-interval start date, builds a unique sAMAccountName from the name fields, adds the correct security groups, moves people on a transfer and disables accounts when the service interval closes with a 30-day grace window — all driven by the HR change in Nmbrs.

“An account is simply ready in the right OU when the new hire walks in, moves between branches sort themselves out, and we can show the auditor exactly which change in Nmbrs created every bit of access.” — Head of IT, wholesale business

The outcome this setup is designed for: onboarding drops from days to zero touch, privilege creep from old roles is eliminated, and the team can walk into its next NIS2 assessment with a complete, source-backed audit trail.