HR to ITSM
Oracle HCM to Jira Service Management integration: customers, organisations and requests from the HCM feeds
With an integration between Oracle HCM Cloud and Jira Service Management, every employee from Oracle is a customer in the service desk, a member of their department's organisation, and every hire, transfer and termination creates a request of the right request type. KoppelHet follows Oracle's feeds, so a hire is ready as an onboarding request weeks before the start.
What the integration does
Organisations that manage their employees in Oracle HCM Cloud and handle IT requests in Jira Service Management have customers there that only appear when someone emails. Without an integration the service desk only sees a transfer from a site abroad when the colleague is at the desk without a workplace.
- HR records the new employee in Oracle, often weeks before the start date.
- KoppelHet sees the hire in Oracle's feed, fetches the employee and creates the customer in Jira Service Management, as a member of their department's organisation.
- Within the agreed lead time before the start an onboarding request follows on behalf of the new colleague, with start date, job and manager in the fields of your request type.
- A different department, job or location results in a change request, and the customer moves to the new organisation.
- On a termination an offboarding request arrives a week before the last working day. The day after the last working day KoppelHet revokes portal access.
What to watch for with Oracle HCM Cloud and Jira Service Management
- Oracle reports a new employee, a changed assignment and a termination each in its own feed. KoppelHet chooses the request type per feed, so a new colleague gets an onboarding request and a transfer a change request, without anyone comparing data.
- An Oracle feed says what happened, but not all the details. KoppelHet then fetches the employee, and only creates a customer once the work email is known, because Jira Service Management creates customers by email address.
- Departments in Oracle often get a new name in a reorganisation. KoppelHet keeps the Oracle ID as a property on the organisation in Jira Service Management, so a renamed department stays the same organisation, with its members and open requests.
- An employee can have several assignments in Oracle, sometimes with different employers in the group. For this service desk only the primary assignment with the Dutch employer counts; it decides the organisation and the manager in the request.
- A transfer from another country to the Dutch employer is a new colleague for this service desk. KoppelHet then creates an onboarding request for the workplace, with the existing person number, so earlier requests from the same person can still be found.
- A termination is often fixed well ahead in Oracle. KoppelHet keeps portal access up to and including the last working day and revokes it the day after, so the colleague can ask IT a question until their last day.
- The manager of a Dutch colleague sometimes works in another country and is then not a customer in this service desk. In that case KoppelHet puts the manager in the request as text and not as a participant, so the request does not get stuck on an unknown account.
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 anything need to be built in Oracle, such as an HCM Extract?
No. The feeds and the REST API are standard. Only an integration user with read rights is needed.
Which request types does the integration use?
Yours, for example onboarding, change and offboarding. At the start we record which field in each request type receives which Oracle detail.
Do colleagues from other countries also go into the service desk?
Only if this service desk serves them. By default KoppelHet only includes the Dutch employer.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Oracle HCM Cloud is read through the Atom feeds newhire, empassignment and termination and the workstructures feeds for departments and locations, then the worker with assignments through the HCM REST API. Read-only integration user; KoppelHet remembers how far each feed has been read. Filter on the primary assignment with the Dutch legal employer.
- 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 (PUT organization/{organizationId}/property/{propertyKey}). Requests through POST /rest/servicedeskapi/request with serviceDeskId, requestTypeId, requestFieldValues and raiseOnBehalfOf; the fields per request type through GET servicedesk/{serviceDeskId}/requesttype/{requestTypeId}/field.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Oracle HCM Cloud | Field in Jira Service Management | Notes |
|---|---|---|
Person number | Klant-eigenschap en verzoekveld personeelsnummer | Stays the same on a transfer within the group |
Voornaam en achternaam | customer displayName | |
Werk-e-mailadres | customer email | |
Department (primaire assignment) | organization | Oracle ID of the department as an organisation property |
Job en manager (assignment) | requestFieldValues: functie en manager | |
Startdatum (newhire) | Request type onboarding met startdatum | |
Gewijzigde assignment (empassignment) | Request type wijziging | |
Einddatum (termination) | Request type offboarding, daarna revoke-portal-only-access | |
Gesynchroniseerde klant | raiseOnBehalfOf (accountId) | The request is in the employee's name |
Related
Ashby → Oracle HCM Cloud
Ashby to Oracle HCM integration: an accepted offer on an opening becomes a pending worker
Bullhorn → Oracle HCM Cloud
Bullhorn to Oracle HCM integration: an approved placement of an employee becomes a pending worker
Carerix → Oracle HCM Cloud
Carerix to Oracle HCM integration: successful placement as a pending worker in Oracle HCM Cloud
Greenhouse → Oracle HCM Cloud
Greenhouse to Oracle HCM integration: accepted offer as a pending worker in Oracle HCM Cloud