How does Joinly sync Paycom to Active Directory?

Joinly reads each HR change in Paycom in the cloud, then hands the action to the Joinly AD Agent inside your network, which makes the change in Active Directory. Paycom holds the authoritative employee and position record; the agent is the only component that touches your domain — and the Paycom side is configured once against the restricted API access your representative provisions.

1. Joiner. HR completes the hire in Paycom. Joinly reads the new record, determines the role from the assigned position, department 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 — timed to the start date on the Paycom record.

2. Mover. When someone changes position, department or location in Paycom, Joinly tells the agent to move the user to the matching OU, swap security-group membership and update attributes. Because Paycom ties job details to the position, a position change is a clean signal, and access that no longer fits is removed.

3. Leaver. On the termination date, Joinly instructs the agent to disable the AD account and optionally move it to a disabled-users OU. Where a person exists under more than one EIN, the account is only disabled when the last active employment ends.

Example: A construction firm runs Paycom and an on-premise AD across three regional offices. It hires a site coordinator with a start date next Monday, assigned to the Site Operations position at its Denver location. Joinly reads the record, and on Monday morning the AD Agent creates the user in the Denver > Operations OU, sets the sAMAccountName to a unique pattern, and adds the Site-Operations group. When the coordinator later moves into a project-manager position, 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 Paycom export that an admin works through in Active Directory Users and Computers by hand — creating the object, choosing the OU, building the sAMAccountName, adding groups. Because Paycom has no native SCIM and no first-party provisioning, there is no out-of-the-box path at all, and the export itself is the bottleneck: getting clean data out of Paycom’s restricted API is the hard part before any AD work even begins.

• Onboarding delays. New joiners wait for an AD account and group access while someone runs a Paycom export and processes it by hand, losing productive days in their first week.

• Permissions that don’t keep up (privilege creep). When movers change position or location, 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 multi-EIN employment it is easy to disable an account while another employment is still active.

Joinly vs. a Paycom SCIM-gateway bridge for AD

Paycom has no native SCIM and no first-party path to on-premise AD, so the real comparison is against third-party middleware — a SCIM gateway like Aquera or a bridge like RoboMQ Hire2Retire that writes Paycom data to AD. Here’s how the two compare for a Paycom-driven AD setup.

Watch-outs when connecting Paycom to Active Directory

A few Paycom-specific details decide whether this connection stays reliable at scale — and the first one is the connection itself.

• Restricted API access. Paycom has no public API. Access is provisioned per customer by a Paycom representative, who sets up an API user with the right permissions, issues an API SID and Token, and often whitelists the calling IP. Joinly handles this gated setup once during onboarding, so getting clean data out of Paycom is solved before any AD object is ever created.

• Rate limits and proprietary schema. Paycom rate-limits the API (around 500 calls per minute on some plans) and its field set is proprietary and varies by implementation. Joinly reads within the limits and maps your specific Paycom fields explicitly, so a heavy import never trips the limit or breaks on a renamed field.

• OU placement from position and location. Paycom position, department and location don’t map one-to-one to your OU structure. Joinly builds explicit rules that place each user — and move them on a position change — into the correct OU.

• Multi-EIN employment. Larger organisations run multiple EINs, and the same person can appear under more than one. Joinly resolves the person across EINs to a single, stable AD object, so a second EIN-level employment adds groups rather than creating a duplicate account.

• 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 Paycom 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 construction firm with around 1,800 employees across a head office and a dozen project sites, running Paycom but still living in an on-premise Active Directory for its project and scheduling systems. Every new hire starts as a Paycom export that IT processes by hand in AD — creating the object, choosing the OU, building the login, adding groups. With seasonal crews and frequent moves between sites the queue never empties, and getting current data out of Paycom is the slow part: the restricted API was set up once, long ago, and nobody wants to touch it.

Connect Paycom to Active Directory with Joinly and that work disappears. The Joinly AD Agent creates each user in the right OU on the start date, builds a unique sAMAccountName, adds the correct security groups, moves people on a position change and disables accounts on the termination date with a 30-day grace window — all driven by the HR change in Paycom, read once through the API Joinly configured for you.

“Pulling clean data out of Paycom used to be the slow part of every hire. Now an account is simply ready in the right OU when the coordinator walks on site, moves between sites move themselves, and we can show the auditor exactly which Paycom change created every bit of access.” — Head of IT, construction firm

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