HR to ITSM
Unit4 HR to Jira Service Management integration: customers per organisational unit and requests for joiners and leavers
With an integration between Unit4 HR (ERPx) and Jira Service Management, every employee from Unit4 is a customer in the service desk, in the organisation of their main position, and a new employee, a transfer or an end date automatically creates a request of the right request type. After the last working day KoppelHet revokes portal access.
What the integration does
Organisations that use Unit4 for HR and finance and handle IT requests in Jira Service Management often add new colleagues to the customer portal by hand. Leavers stay there, and IT only notices a move to another unit when the employee raises a ticket themselves.
- Every hour KoppelHet fetches the employees that changed in Unit4 since the previous run.
- A new organisational unit first becomes an organisation in Jira Service Management, then the customer follows with their work email.
- Within the agreed lead time before the start date, KoppelHet raises the onboarding request on behalf of the manager.
- A relation with a later effective date produces a change request on that date, and the customer moves to the new organisation.
- An end date gives an offboarding request; the day after the last working day portal access is revoked.
What to watch for with Unit4 HR and Jira Service Management
- In Unit4, personId is only unique within one company; a second company in the same environment can use the same number. Jira Service Management recognises customers by email address and accountId. KoppelHet therefore records itself which accountId belongs to which combination of companyId and personId, so a request never lands with the wrong colleague.
- An employee can hold several positions in Unit4, but an organisation in Jira Service Management works best with one unit per customer. KoppelHet places the customer only in the organisation of the position marked as main position, so approvals and visibility are not spread across two teams.
- Relations in Unit4, such as unit and manager, have a dateFrom and dateTo. HR often records a transfer weeks ahead. KoppelHet creates the change request on the dateFrom and only moves the customer then, so IT does not grant rights of the new department too early.
- Unit4 recommends reading incrementally with ge on lastUpdated/updatedAt, and warns that the same record can then come back twice. KoppelHet stores per employee which request has already been raised per event, so a record delivered twice does not put a second onboarding request in the queue.
- If an employee is deleted in Unit4, Unit4 sets the status to Terminate instead of removing the record. KoppelHet treats that status as a departure, with an offboarding request and revoked portal access, and not as a missing record that is silently ignored.
- The machine-to-machine user of a Unit4 integration needs the SUPER or SYSTEM role, and according to Unit4 the token only establishes who is calling, not what they may do. KoppelHet therefore only requests the employee object and only sends name, work email, unit, manager and dates to Jira; pay and bank details stay in Unit4.
- Unit4 allows ten machine-to-machine clients per tenant and shares a limit of 500 calls per minute across all of them. KoppelHet only reads changed employees, so the service desk integration does not take capacity from finance and project integrations on the same tenant.
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 this work with several companies in one Unit4 environment?
Yes. KoppelHet distinguishes employees by company and number, and per company you can choose your own request type or service desk.
Do existing employees get a request at go-live?
No. The first run only creates customers and organisations. Requests follow from new employees, transfers and end dates.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Unit4 ERPx through the ObjectAPI (GET /v1/objects/employees, read-only) with OAuth 2.0 client credentials through Unit4 Identity Services (scope u4erp, token 3600 seconds, user with SUPER or SYSTEM role), incremental on lastUpdated/updatedAt with ge. Fields include companyId, personId, nameInformation, contactPoints, status, employments and relatedValues with dateFrom and dateTo. Limits: 50,000 records per call, 500 calls per minute per tenant, ten M2M clients.
- Jira Service Management through /rest/servicedeskapi/: POST customer (email, displayName; Jira Administrator), POST organization and POST organization/{id}/user, PUT organization/{id}/property/{key} (visible through the API only, up to 32,768 bytes of JSON) and PUT customer/user/{accountId}/revoke-portal-only-access (site admin).
- Requests through POST /rest/servicedeskapi/request with serviceDeskId, requestTypeId, requestFieldValues and raiseOnBehalfOf. KoppelHet stores the issue key per event for each employee and adds a later date change as a comment on the open request.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Unit4 HR | Field in Jira Service Management | Notes |
|---|---|---|
companyId + personId | Sleutel in KoppelHet bij het accountId van de klant | personId is only unique within a company |
nameInformation.firstName + surname | customer displayName | |
Zakelijk e-mailadres (contactPoints) | customer email | |
Organisatie-eenheid van de hoofdpositie | organization | Unit4 code as organisation property |
Relatie leidinggevende | raiseOnBehalfOf | |
employmentStartDate | Request type onboarding (requestFieldValues: startdatum) | |
Relatie met nieuwe dateFrom | Request type wijziging | |
employmentEndDate | Request type offboarding, daarna revoke-portal-only-access |
Related
Greenhouse → Unit4 HR
Greenhouse to Unit4 HR integration: accepted offer as an employee in the right Unit4 company
Recruitee → Unit4 HR
Recruitee to Unit4 HR integration: hired candidate as employee in Unit4, validated before it is saved
SmartRecruiters → Unit4 HR
SmartRecruiters to Unit4 HR integration: hire on the position from SmartRecruiters, with onboarding status back
Teamtailor → Unit4 HR
Teamtailor to Unit4 HR integration: hired candidates as employees in Unit4 ERPx, with company and position