HR naar ITSM
Unit4 HR koppelen met Jira Service Management: klanten per organisatie-eenheid en verzoeken bij in- en uitdienst
Met een koppeling tussen Unit4 HR (ERPx) en Jira Service Management staat elke medewerker uit Unit4 als klant in de servicedesk, in de organisatie van zijn hoofdpositie, en maakt een nieuwe medewerker, een overplaatsing of een einddatum automatisch een verzoek van het juiste request type. Na de laatste werkdag trekt KoppelHet de portaaltoegang in.
Wat de koppeling doet
Organisaties die Unit4 voor HR en financiën gebruiken en IT-verzoeken in Jira Service Management afhandelen, zetten nieuwe collega's vaak met de hand in het klantportaal. Wie vertrekt, blijft daar staan, en een verhuizing naar een andere eenheid ziet IT pas als de medewerker zelf een ticket maakt.
- KoppelHet haalt elk uur de medewerkers op die in Unit4 sinds de vorige ronde zijn gewijzigd.
- Een nieuwe organisatie-eenheid wordt eerst een organisatie in Jira Service Management, daarna volgt de klant met zijn zakelijke adres.
- Binnen de afgesproken termijn voor de begindatum dient KoppelHet het onboardingverzoek in namens de leidinggevende.
- Een relatie met een latere ingangsdatum levert op die datum een wijzigingsverzoek op, en de klant verhuist naar de nieuwe organisatie.
- Een einddatum geeft een offboardingverzoek; de dag na de laatste werkdag wordt de portaaltoegang ingetrokken.
Waar je op let bij Unit4 HR en Jira Service Management
- In Unit4 is personId alleen binnen één bedrijf uniek; een tweede bedrijf in dezelfde omgeving kan hetzelfde nummer gebruiken. Jira Service Management herkent klanten aan hun e-mailadres en accountId. KoppelHet legt daarom zelf vast welk accountId bij welke combinatie van companyId en personId hoort, zodat een verzoek nooit bij de verkeerde collega terechtkomt.
- Een medewerker kan in Unit4 meer posities hebben, maar een organisatie in Jira Service Management werkt het best met één eenheid per klant. KoppelHet plaatst de klant alleen in de organisatie van de positie die als hoofdpositie is gemarkeerd, zodat goedkeuringen en zichtbaarheid niet over twee teams verspreid raken.
- Relaties in Unit4, zoals eenheid en leidinggevende, hebben een dateFrom en dateTo. HR legt een overplaatsing vaak weken vooruit vast. KoppelHet maakt het wijzigingsverzoek op de dateFrom en verplaatst de klant pas dan, zodat IT niet te vroeg rechten van de nieuwe afdeling uitdeelt.
- Unit4 raadt aan incrementeel te lezen met ge op lastUpdated/updatedAt, en waarschuwt dat hetzelfde record dan twee keer kan terugkomen. KoppelHet bewaart per medewerker welk verzoek per gebeurtenis al is ingediend, zodat een dubbel geleverd record geen tweede onboardingverzoek in de wachtrij zet.
- Wordt een medewerker in Unit4 verwijderd, dan zet Unit4 de status op Terminate in plaats van het record weg te halen. KoppelHet behandelt die status als vertrek, met een offboardingverzoek en ingetrokken portaaltoegang, en niet als een ontbrekend record dat stil wordt genegeerd.
- De machine-to-machine-gebruiker van een Unit4-koppeling heeft de rol SUPER of SYSTEM nodig, en volgens Unit4 bepaalt het token alleen wie er belt, niet wat die mag. KoppelHet vraagt daarom alleen het medewerkerobject op en stuurt alleen naam, werkadres, eenheid, leidinggevende en datums naar Jira; salaris en bankgegevens blijven in Unit4.
- Unit4 staat per tenant tien machine-to-machine-clients toe en deelt een limiet van 500 aanroepen per minuut over al die clients. KoppelHet leest alleen gewijzigde medewerkers, zodat de servicedeskkoppeling geen ruimte wegneemt van finance- en projectkoppelingen op dezelfde tenant.
Deze koppeling hoort ook bij in-, door- en uitstroom.
Hoe we het bouwen en beheren
- De koppeling draait op het KoppelHet platform, gehost in een datacenter in de EU.
- Elke synchronisatie en elke fout is zichtbaar in de functionele logging; bij een fout krijgt jullie beheerder een melding.
- Een mutatie die niet door kan, wordt niet half doorgezet maar klaargezet om opnieuw te proberen.
- KoppelHet is ISO 27001-gecertificeerd. Gegevens gaan versleuteld over en blijven niet langer op het platform dan nodig.
- Na livegang beheren wij de koppeling en passen we hem aan als jullie proces verandert.
- De koppeling past naast je bestaande integratielaag. Alleen de velden uit het ontwerp gaan over; het platform houdt geen eigen registratie bij.
Implementatie en prijs
Dit is geen app die je aanzet. We bouwen de koppeling voor jullie organisatie op ons platform, met bouwstenen die we steeds opnieuw gebruiken. Zo is het maatwerk, zonder dat we bij nul beginnen.
Een consultant bereidt de intake voor en analyseert beide systemen. Daarna leggen we de mapping en uitzonderingen per veld vast, testen we in de test- of acceptatieomgeving en gaan we live op een moment dat jij kiest. De kosten bestaan uit een eenmalig bedrag voor de inrichting en een maandbedrag voor platform, monitoring en beheer.
Veelgestelde vragen
Werkt dit met meerdere bedrijven in één Unit4-omgeving?
Ja. KoppelHet onderscheidt medewerkers op bedrijf en nummer, en per bedrijf kunnen jullie een eigen request type of servicedesk kiezen.
Krijgen bestaande medewerkers bij livegang een verzoek?
Nee. De eerste ronde maakt alleen klanten en organisaties aan. Verzoeken volgen uit nieuwe medewerkers, overplaatsingen en einddatums.
Technische details voor IT
Voor wie wil weten hoe het onder de motorkap werkt: gebruikte API's, velden en bronnen.
- Unit4 ERPx via de ObjectAPI (GET /v1/objects/employees, alleen lezen) met OAuth 2.0 client credentials via Unit4 Identity Services (scope u4erp, token 3600 seconden, gebruiker met rol SUPER of SYSTEM), incrementeel op lastUpdated/updatedAt met ge. Velden onder meer companyId, personId, nameInformation, contactPoints, status, employments en relatedValues met dateFrom en dateTo. Limieten: 50.000 records per aanroep, 500 aanroepen per minuut per tenant, tien M2M-clients.
- Jira Service Management via /rest/servicedeskapi/: POST customer (email, displayName; Jira Administrator), POST organization en POST organization/{id}/user, PUT organization/{id}/property/{key} (alleen via de API zichtbaar, maximaal 32.768 bytes JSON) en PUT customer/user/{accountId}/revoke-portal-only-access (site-admin).
- Verzoeken via POST /rest/servicedeskapi/request met serviceDeskId, requestTypeId, requestFieldValues en raiseOnBehalfOf. KoppelHet bewaart per medewerker de issuekey per gebeurtenis en zet een latere wijziging van de datum als opmerking op het openstaande verzoek.
Welke velden overgaan
De belangrijkste velden. De volledige mapping stellen we per klant vast.
| Veld in Unit4 HR | Veld in Jira Service Management | Toelichting |
|---|---|---|
companyId + personId | Sleutel in KoppelHet bij het accountId van de klant | personId is alleen binnen een bedrijf uniek |
nameInformation.firstName + surname | customer displayName | |
Zakelijk e-mailadres (contactPoints) | customer email | |
Organisatie-eenheid van de hoofdpositie | organization | Unit4-code als organisatie-eigenschap |
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 |
Gerelateerd
Greenhouse → Unit4 HR
Greenhouse Unit4 HR koppeling: geaccepteerd aanbod als medewerker in het juiste Unit4-bedrijf
Recruitee → Unit4 HR
Recruitee Unit4 HR koppeling: aangenomen kandidaat als medewerker in Unit4, gecontroleerd voordat hij wordt opgeslagen
SmartRecruiters → Unit4 HR
SmartRecruiters Unit4 HR koppeling: aanname op de positie uit SmartRecruiters, met onboardingstatus terug
Teamtailor → Unit4 HR
Teamtailor Unit4 HR koppeling: aangenomen kandidaten als medewerker in Unit4 ERPx, met bedrijf en positie