HR to ITSM
Deel to Jira Service Management integration: EOR staff, contractors and own employees in one service desk
With an integration between Deel and Jira Service Management, everyone working through Deel becomes a customer in the service desk, with the type of relationship included, and a signed contract, a change or an end date creates a request of the right request type. IT then arranges the laptop for an EOR employee abroad as promptly as for a colleague at the office.
What the integration does
Organisations that have people in several countries working through Deel, as employer of record or as contractors, and handle IT requests in Jira Service Management miss the people in the service desk who have never emailed. Without an integration a contractor whose contract ends sometimes keeps access to the portal and tools for weeks.
- A new colleague's contract is signed in Deel, often weeks before the start.
- KoppelHet creates the customer in Jira Service Management as soon as the work email is known, as a member of their department's organisation.
- Within the agreed lead time before the start an onboarding request follows on behalf of the colleague, with country, type of relationship and manager.
- A different department or job results in a change request.
- One week before the end date an offboarding request arrives. The day after the last working day KoppelHet revokes portal access.
What to watch for with Deel and Jira Service Management
- Deel has own employees, EOR employees and contractors. For the service desk everyone is a customer, but the request type can differ. A contractor with their own laptop gets a short onboarding request for accounts only, an EOR employee a request with a laptop to their country.
- Deel sometimes reports a signed contract months before the start, while the work email does not exist yet. Jira Service Management creates customers by email address. KoppelHet therefore waits with the customer until the work email is in Deel, and flags it if that happens too close to the start date.
- Contractors usually have an end date in Deel. If the contract is extended, that date moves and the offboarding request only follows for the new end date. An extension therefore produces no request that IT has to close again.
- If a contractor or EOR employee moves to your own entity, Deel creates a new contract for the same person. KoppelHet keeps the customer and their organisation the same and creates a change request, not an offboarding plus onboarding, so their earlier requests stay with them.
- Departments in Deel are renamed in a reorganisation. KoppelHet keeps the Deel ID on the organisation in Jira Service Management, so a renamed department stays the same organisation.
- Deel disables a webhook after ten failed delivery attempts. KoppelHet monitors this and compares the active people in Deel with the customers in the service desk every day, so a missed notification does not leave a contractor with access after their end date.
- KoppelHet checks the signature of every notification from Deel. A forged notification therefore cannot cause an offboarding request or revoked portal access.
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
Do contractors get access to the customer portal?
Yes, if you want them to. They get the same customer access as own employees, up to and including their last working day.
Do contract or salary details go to Jira?
No. Only name, work email, department, job, country, manager, type of relationship and the start and end date.
Do existing people get a request at go-live?
No. The first run only creates customers and organisations. Requests follow from new contracts, changes and end dates.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Deel is read through the HRIS People API (worker_id, preferred_first_name, last_name, work_email, job_title, department, direct_manager, hiring_type, work_location, employments with termination_last_day) and signed webhooks (x-deel-signature, HMAC-SHA256) with ten delivery attempts up to sixteen hours, using a read-only token.
- Jira Service Management through the REST API under /rest/servicedeskapi/ - POST customer, PUT customer/user/{accountId}/revoke-portal-only-access, organization with users and properties. Requests through POST /rest/servicedeskapi/request with serviceDeskId, requestTypeId, requestFieldValues and raiseOnBehalfOf; KoppelHet stores the request per event for each worker.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Deel | Field in Jira Service Management | Notes |
|---|---|---|
worker_id | Klant-eigenschap en verzoekveld Deel-id | Per person, not per contract |
preferred_first_name of first_name en last_name | customer displayName | |
work_email | customer email | |
department.name | organization | Deel ID of the department as a property |
hiring_type | requestFieldValues: soort arbeidsrelatie | |
work_location of land van het contract | requestFieldValues: land | |
direct_manager | requestFieldValues: manager | |
Startdatum contract | Request type onboarding | |
termination_last_day of einddatum contract | Request type offboarding, daarna revoke-portal-only-access |
Related
Ashby → Deel
Ashby to Deel integration: hires at the own entity as direct employee in Deel
Bullhorn → Deel
Bullhorn to Deel integration: first placement as a direct employee with a contract in Deel
Carerix → Deel
Carerix to Deel integration: successful placement as a person or contract in Deel
Deel → 4PS Construct
Deel to 4PS Construct integration: own employees of the construction entity in 4PS, with department and cost centre as dimensions