HR naar ITSM
Remote koppelen met Jira Service Management: klanten per land en verzoeken bij start en offboarding
Met een koppeling tussen Remote en Jira Service Management wordt iedereen die via Remote werkt een klant in jullie servicedesk, in de organisatie van zijn land, en maakt KoppelHet een onboardingverzoek van het juiste request type zodra de employment in Remote actief wordt. Is de offboarding in Remote naar payroll doorgezet, dan volgt een offboardingverzoek en na de einddatum gaat de portaaltoegang dicht.
Wat de koppeling doet
Organisaties die via Remote in meerdere landen mensen in dienst hebben en hun IT-servicedesk in Jira Service Management draaien, maken klanten en verzoeken vaak met de hand aan na een bericht van HR. Een vertrek dat Remote nog juridisch toetst, staat dan soms al als ticket bij IT.
- KoppelHet laadt eenmalig alle employments uit Remote en volgt daarna de webhooks.
- Zodra er een werkadres is, maakt KoppelHet de klant aan en voegt hem toe aan de organisatie van zijn land.
- Wordt de employment actief, dan maakt KoppelHet het onboardingverzoek namens de klant, met het request type bij het werkmodel.
- Gaat de offboarding naar payroll, dan volgt het offboardingverzoek met de einddatum.
- Na de einddatum trekt KoppelHet de portaaltoegang in.
Waar je op let bij Remote en Jira Service Management
- Remote onderscheidt werkmodellen (EOR, PEO, global payroll) en soorten employment, zoals werknemer en contractor. KoppelHet kiest daarmee het request type, zodat een contractor via Remote een kort verzoek voor alleen accounts krijgt en een EOR-medewerker een verzoek met een laptop naar zijn land.
- Een klant aanmaken vraagt in Jira Service Management de globale Jira-beheerdersrechten, portaaltoegang intrekken zelfs sitebeheer, en een endpoint om die toegang terug te geven is er niet. KoppelHet trekt de toegang daarom pas in na de vastgestelde einddatum uit Remote, nooit al bij het begin van een offboarding.
- Remote toetst bij een offboarding eerst de juridische en contractuele opzegtermijnen, en raadt aan de medewerker pas daarna in te lichten. KoppelHet maakt het offboardingverzoek daarom pas bij de melding dat de offboarding naar payroll is doorgezet, en slaat vertrouwelijke offboardings over.
- Een organisatie aanmaken met een naam die al bestaat, geeft in Jira Service Management de bestaande organisatie terug. KoppelHet gebruikt dat om per land precies één organisatie te houden, ook als twee employments in hetzelfde land tegelijk binnenkomen.
- Organisatie-eigenschappen in Jira Service Management zijn alleen via de API te zien en mogen tot 32.768 bytes groot zijn. KoppelHet bewaart daar de landcode uit Remote, zodat een hernoemde organisatie in de servicedesk nog steeds bij het juiste land hoort.
- Het werkadres staat in Remote soms later vast dan de rest, en Remote meldt die wijziging apart. Jira Service Management maakt klanten op e-mailadres, dus KoppelHet maakt de klant pas bij die melding aan, en laat het onboardingverzoek tot dan op naam van de leidinggevende.
- Remote herhaalt een melding alleen als de verbinding mislukt; een foutantwoord geldt als afgeleverd. Gaat de verwerking bij KoppelHet mis, bijvoorbeeld omdat Jira Service Management even niet bereikbaar is, dan speelt KoppelHet de melding opnieuw af via de replayfunctie van Remote, met een OAuth-integratietoken.
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
Heeft Jira Service Management een Remote-koppeling?
We vonden er geen van Atlassian of Remote; wel een no-code-sjabloon bij een automatiseringsplatform. KoppelHet bouwt op de API's van beide kanten.
Waarom heeft het koppelaccount zoveel rechten in Jira?
Klanten aanmaken en portaaltoegang intrekken kan volgens Atlassian alleen met beheerdersrechten. Wil je dat niet, dan kan KoppelHet het intrekken als taak in het offboardingverzoek zetten.
Technische details voor IT
Voor wie wil weten hoe het onder de motorkap werkt: gebruikte API's, velden en bronnen.
- Remote via de Remote API: GET /v1/employments (page_size 100) en GET /v1/employments/{employment_id}; webhooks via POST /v1/webhook-callbacks op employment.status.updated, employment.details.updated, employment.work_email.updated, offboarding.submitted_to_payroll en offboarding.deleted, met X-Remote-Signature en X-Remote-Timestamp. Retries alleen bij transportfouten, tot vijf keer; replay via POST /v1/webhook-events/replay met webhook.read en webhook.write.
- Jira Service Management via /rest/servicedeskapi/: POST customer (email, displayName; Jira-beheerdersrechten), PUT customer/user/{accountId}/revoke-portal-only-access (sitebeheer), POST organization (geeft de bestaande terug bij dezelfde naam), POST organization/{id}/user en PUT organization/{id}/property/{key}. Verzoeken via POST request met serviceDeskId, requestTypeId, requestFieldValues en raiseOnBehalfOf (niet voor gebruikers met alleen klantrechten).
Welke velden overgaan
De belangrijkste velden. De volledige mapping stellen we per klant vast.
| Veld in Remote | Veld in Jira Service Management | Toelichting |
|---|---|---|
employment_id | Verzoekveld Remote-id en sleutel bij KoppelHet | |
full_name | displayName | |
Werkadres | email | Klant pas aanmaken als dit er is |
Land van de employment | organization (één per land) | |
department | requestFieldValues: afdeling | |
employment_model en employment_type | requestTypeId | Ander request type voor contractors |
status active | Onboardingverzoek | |
offboarding.submitted_to_payroll | Offboardingverzoek, daarna revoke-portal-only-access |
Gerelateerd
Greenhouse → Remote
Greenhouse Remote koppeling: buitenlandse aannames als EOR-employment met het formulier van het land
Recruitee → Remote
Recruitee Remote koppeling: buitenlandse aannames direct als employment bij Remote
Remote → 4PS Construct
Remote 4PS Construct koppeling: eigen medewerkers van de bouwentiteit uit Remote in 4PS
Remote → Active Directory
Remote Active Directory koppeling: accounts voor collega's in andere landen