Identity and access management
Dayforce to Active Directory integration: domain accounts per location from Dayforce
With an integration between Dayforce and Active Directory, KoppelHet creates a domain account for new employees of the Dutch organisation in Dayforce in their location's OU, with job, department and manager. After the end date in Dayforce the account is disabled, and that date is set in advance as the account's expiry date.
What the integration does
Organisations where a foreign parent company manages Dayforce and the Dutch sites have their own Active Directory create accounts by hand after an email from HR. The manager in the domain is rarely right.
- IT installs a small KoppelHet program once on a server in the domain.
- KoppelHet's platform asks Dayforce which employees of the Dutch organisation were updated, hired or terminated.
- The program creates the account in the location's OU, with job, department and manager, and sets the groups that go with the job.
- A new location or job in Dayforce moves the account and changes the groups.
- After the end date the account is disabled and moved to the leavers OU.
What to watch for with Dayforce and Active Directory
- Dayforce has a fixed reference code per employee and also an employee number that can differ per organisation. KoppelHet puts the reference code on the account as key and the employee number in Active Directory's second number field, so both can be looked up.
- Locations in Dayforce are part of an organisation tree with several levels. KoppelHet uses the location from the primary work assignment to choose the OU, so group policy per distribution centre is right.
- Dayforce distinguishes active, inactive and terminated employees. Inactive often means long-term leave; whether the account is then disabled or stays active is agreed per status.
- A termination is often entered weeks ahead in Dayforce. KoppelHet sets the end date as the account's expiry date straight away, so it also stops on time if the program in the domain is not running that day.
- Not every employee in a distribution centre works at a PC. Per job we agree who gets a domain account, so no unused accounts are created.
- KoppelHet's platform reads Dayforce; the program in the domain only collects instructions over an outbound connection. The domain therefore needs no access to Dayforce and nothing needs opening in the firewall.
This integration is also part of joiner, mover, leaver.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Does a port need to be opened in our firewall?
No. The program in your domain only makes an outbound connection to KoppelHet's platform.
Does this also work without Active Directory, with Microsoft 365 only?
Yes, we build that integration too.
What can be traced afterwards for an audit?
Every action of the integration is recorded in the audit logging of the KoppelHet platform. KoppelHet works with an ISO 27001 certified management system.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Dayforce is read through the RESTful Web Services (Employees with filterUpdatedStartDate, filterUpdatedEndDate and filterUpdatedEntities, filterHireStartDate, filterTerminationStartDate, orgUnitXRefCode and employmentStatusXRefCode), then per XRefCode with expand for WorkAssignments, EmploymentStatuses and EmployeeManagers, with contextDate.
- A KoppelHet agent on a Windows server in the domain writes employeeID (at most 16 characters), employeeNumber, sAMAccountName (at most 20 characters), userPrincipalName, givenName, sn, displayName, title, department, physicalDeliveryOfficeName, manager and accountExpires, and moves accounts between OUs.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Dayforce | Field in Active Directory | Notes |
|---|---|---|
XRefCode | employeeID | Fixed key; at most 16 characters |
EmployeeNumber | employeeNumber | |
FirstName | givenName | |
LastName | sn en displayName | |
Naamgevingsregel | sAMAccountName en userPrincipalName | sAMAccountName at most 20 characters |
WorkAssignments (primair): Location | OU en physicalDeliveryOfficeName | |
WorkAssignments (primair): Department | department | |
WorkAssignments (primair): Job | title en groepen | |
EmployeeManagers | manager | Distinguished name of the manager's account |
Termination date | accountExpires en uitschakelen |
Related
Ashby → Dayforce
Ashby to Dayforce integration: have Dayforce validate the hire first, then save it
Bullhorn → Dayforce
Bullhorn to Dayforce integration: first placement of an employee as an employee in Dayforce
Carerix → Dayforce
Carerix to Dayforce integration: successful placement as a validated new employee in Dayforce
Dayforce → 4PS Construct
Dayforce to 4PS Construct integration: technicians and site managers from Dayforce in 4PS, with cost centre and end date