HR to ITSM
Dayforce to Jira Service Management integration: customers per org unit and requests on joining and leaving
With an integration between Dayforce and Jira Service Management, every employee from Dayforce is a customer in the service desk portal, in the organisation of their org unit, and KoppelHet raises a request of the right request type when someone is hired or leaves in Dayforce. The request is in the manager's name, with the start date or end date from Dayforce in it.
What the integration does
Organisations that keep employee records, schedules and pay in Dayforce and handle IT requests in Jira Service Management often retype hires and departures in a portal form. Customers in the portal then belong to no organisation, so agents cannot see which part of the organisation a request comes from.
- KoppelHet asks Dayforce which employees changed in employment status, work assignment or manager since the previous round.
- New org units first become an organisation in Jira Service Management, then the customer follows.
- Every morning KoppelHet looks for hires with a start date within the onboarding lead time and raises one onboarding request per person.
- A transfer moves the customer to the organisation of the new unit on the effective date.
- An end date within a week produces the offboarding request; after that date the service desk revokes portal access.
What to watch for with Dayforce and Jira Service Management
- Creating a customer through the Jira Service Management API requires the global Jira administrator permission. Organisations and requests also work with agent rights. KoppelHet therefore uses two accounts, so the account that raises requests every day is not an administrator.
- Raising a request on behalf of someone else is not possible with an account that only has customer permission. KoppelHet raises the onboarding request on behalf of the manager from Dayforce, because the new employee often has no work address yet to log in as a customer.
- A customer in Jira Service Management only has a name, email address and accountId, no employee number. KoppelHet keeps per employee which accountId belongs to which Dayforce XRefCode, so a name change or new email address updates the same customer.
- Dayforce can filter employees by org unit. Every unit that belongs to the service desk becomes an organisation in Jira Service Management, so agents see per customer which unit a request comes from and reports per unit add up.
- Dayforce can search employees by a range of hire dates. Every morning KoppelHet requests the hires whose start date falls within the onboarding lead time, so a hire recorded months ahead does not put a request in the queue too early.
- The filter on changed parts only works in Dayforce when both a start and end date are given; otherwise Dayforce looks at all parts. KoppelHet always sends both, so a changed bank account does not update the customer in the portal.
- Dayforce returns an employee as they are on a chosen date. For a transfer KoppelHet requests the state on the effective date and only moves the customer to the new organisation on that day, so open requests stay visible to the old part of the organisation until then.
- Names only come from Dayforce if the API user's default role has the personal information right and field access is configured. If the name is missing, KoppelHet does not create a nameless customer but reports the rights issue.
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 schedule or pay data go to Jira?
No. Only name, work email, org unit, manager and the start and end dates.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Dayforce through the REST API (GET Employees with FilterUpdatedStartDate, FilterUpdatedEndDate and filterUpdatedEntities, FilterHireStartDate and FilterHireEndDate, FilterTerminationStartDate and FilterTerminationEndDate, OrgUnitXRefCode; then Employees/{xRefCode} with expand and ContextDate). The list only returns XRefCodes.
- Jira Service Management through the REST API: POST /rest/servicedeskapi/customer (displayName, email, fullName; Jira administrator), POST /rest/servicedeskapi/organization and /organization/{organizationId}/user with accountIds (agent or service desk administrator), and POST /rest/servicedeskapi/request with serviceDeskId, requestTypeId, requestFieldValues and raiseOnBehalfOf.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Dayforce | Field in Jira Service Management | Notes |
|---|---|---|
XRefCode | Koppeltabel XRefCode naar accountId | Kept on the KoppelHet platform; a customer has no employee number field |
FirstName en LastName | displayName en fullName van de klant | |
Contacts (werk-e-mail) | email van de klant | |
OrgUnitInfos (organisatie-eenheid) | Organisatie, klant toegevoegd via accountIds | |
EmployeeManagers | raiseOnBehalfOf van het verzoek | |
HireDate | Startdatum in requestFieldValues | |
TerminationDate | Einddatum in het offboardingverzoek |
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