HR to ITSM
Remote to Jira Service Management integration: customers per country and requests at start and offboarding
With an integration between Remote and Jira Service Management, everyone working through Remote becomes a customer in your service desk, in the organisation of their country, and KoppelHet creates an onboarding request of the right request type as soon as the employment in Remote becomes active. Once the offboarding in Remote has been passed to payroll, an offboarding request follows and portal access closes after the end date.
What the integration does
Organisations that employ people in several countries through Remote and run their IT service desk in Jira Service Management often create customers and requests by hand after a message from HR. A departure that Remote is still reviewing legally then sometimes already sits with IT as a ticket.
- KoppelHet loads all employments from Remote once and then follows the webhooks.
- As soon as there is a work email, KoppelHet creates the customer and adds them to the organisation of their country.
- When the employment becomes active, KoppelHet creates the onboarding request on behalf of the customer, with the request type for the employment model.
- When the offboarding goes to payroll, the offboarding request follows with the end date.
- After the end date KoppelHet revokes portal access.
What to watch for with Remote and Jira Service Management
- Remote distinguishes employment models (EOR, PEO, global payroll) and employment types, such as employee and contractor. KoppelHet uses them to choose the request type, so a contractor through Remote gets a short request for accounts only and an EOR employee a request with a laptop to their country.
- Creating a customer in Jira Service Management requires the global Jira administrator permission, revoking portal access even site administration, and there is no endpoint to give that access back. KoppelHet therefore only revokes access after the confirmed end date from Remote, never at the start of an offboarding.
- For an offboarding Remote first checks the legal and contractual notice periods, and advises to only inform the employee after that. KoppelHet therefore only creates the offboarding request on the notification that the offboarding has been passed to payroll, and skips confidential offboardings.
- Creating an organisation with a name that already exists returns the existing organisation in Jira Service Management. KoppelHet uses that to keep exactly one organisation per country, even when two employments in the same country arrive at the same time.
- Organisation properties in Jira Service Management are only visible through the API and can be up to 32,768 bytes. KoppelHet stores the country code from Remote there, so a renamed organisation in the service desk still belongs to the right country.
- The work email in Remote is sometimes fixed later than the rest, and Remote reports that change separately. Jira Service Management creates customers by email address, so KoppelHet only creates the customer on that notification, and keeps the onboarding request in the manager's name until then.
- Remote only repeats a notification when the connection fails; an error response counts as delivered. If processing at KoppelHet fails, for example because Jira Service Management is briefly unreachable, KoppelHet replays the notification through Remote's replay function, with an OAuth integration token.
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 Jira Service Management have a Remote integration?
We found none from Atlassian or Remote; only a no-code template on an automation platform. KoppelHet builds on the APIs of both sides.
Why does the integration account have so many rights in Jira?
According to Atlassian, creating customers and revoking portal access require administrator rights. If you prefer not to grant that, KoppelHet can put the revocation as a task in the offboarding request.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Remote through the Remote API: GET /v1/employments (page_size 100) and GET /v1/employments/{employment_id}; webhooks through POST /v1/webhook-callbacks on employment.status.updated, employment.details.updated, employment.work_email.updated, offboarding.submitted_to_payroll and offboarding.deleted, with X-Remote-Signature and X-Remote-Timestamp. Retries only on transport errors, up to five times; replay through POST /v1/webhook-events/replay with webhook.read and webhook.write.
- Jira Service Management through /rest/servicedeskapi/: POST customer (email, displayName; Jira administrator permission), PUT customer/user/{accountId}/revoke-portal-only-access (site administration), POST organization (returns the existing one for the same name), POST organization/{id}/user and PUT organization/{id}/property/{key}. Requests through POST request with serviceDeskId, requestTypeId, requestFieldValues and raiseOnBehalfOf (not for users with customer permission only).
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Remote | Field in Jira Service Management | Notes |
|---|---|---|
employment_id | Verzoekveld Remote-id en sleutel bij KoppelHet | |
full_name | displayName | |
Werkadres | email | Create customer only once this exists |
Land van de employment | organization (één per land) | |
department | requestFieldValues: afdeling | |
employment_model en employment_type | requestTypeId | Different request type for contractors |
status active | Onboardingverzoek | |
offboarding.submitted_to_payroll | Offboardingverzoek, daarna revoke-portal-only-access |
Related
Greenhouse → Remote
Greenhouse to Remote integration: foreign hires as EOR employment with the country's form
Recruitee → Remote
Recruitee to Remote integration: hires abroad straight into an employment at Remote
Remote → 4PS Construct
Remote to 4PS Construct integration: own employees of the construction entity from Remote in 4PS
Remote → Active Directory
Remote to Active Directory integration: accounts for colleagues in other countries