Personio logoJira Service Management logo

HR to ITSM

Personio Jira Service Management integration: new colleagues in the portal and onboarding requests before they start

With an integration between Personio and Jira Service Management, an employee from Personio is already a customer in the portal and an employee in Assets during onboarding, and KoppelHet raises an onboarding request of your request type on their behalf, with start date, job and manager. An end date results in an offboarding request, and after that date the integration revokes portal access.

What the integration does

Anyone using Personio for HR and Jira Service Management with Assets for IT starts onboarding in Personio weeks before the first working day. IT often only hears about it a few days in advance, too late to get a laptop ready.

  1. HR records a new employee in Personio; onboarding begins.
  2. Personio reports the new employee; KoppelHet fetches the person and the most recent employment.
  3. The employee becomes a portal customer and a member of their department's organisation, and gets an employee object in Assets with start date.
  4. IT links a laptop to the employee object, well before the first working day.
  5. After the contract end date KoppelHet revokes portal access and sets the employee object to out of service.
  6. When the start date falls within the agreed lead time, four weeks by default, KoppelHet creates a request of the onboarding request type on behalf of the new customer, with start date, job and manager in the fields.
  7. A new job or department results in a change request; one week before the last working day an offboarding request arrives for laptop and access.
Personio → KoppelHet → Jira Service ManagementSOURCEPersonioTARGETJira Service ManagementKoppelHetmapping · logging · monitoringPersonio → KoppelHet → Jira Service ManagementSOURCEPersonioTARGETJira Service ManagementKoppelHetmapping · logging · monitoring
Out: Portal customer with name and email · Organisation per department · Employee object in Assets · Office, supervisor and cost centre · Revoking portal access after departure · Onboarding request of the onboarding request type, on behalf of the new employee · Change and offboarding request

What to watch for with Personio and Jira Service Management

  • Because new colleagues are already customers during onboarding in Personio, KoppelHet raises the onboarding request on their behalf. They follow its status in the portal before their first working day.
  • An external from Personio can get their own request type, for example accounts only and no laptop. The type INTERNAL or EXTERNAL decides which request type KoppelHet chooses.
  • The offboarding request arrives one week before employment_end_date. If the employee then gets a new employment after all, KoppelHet adds a comment to the request that the departure is off.
  • Onboarding in Personio begins before the start date, with its own status. KoppelHet already creates the customer and the employee object in that phase, so IT can prepare the laptop while the new colleague does not yet need portal access.
  • Not every change in Personio sends a notification. Alongside the direct notifications a periodic comparison therefore runs, so a new office, for example, still reaches Assets.
  • Personio mixes departments and teams. KoppelHet only turns departments into organisations in Jira Service Management, so customers do not disappear into dozens of small team organisations.
  • Personio distinguishes own employees from externals. Both can get hardware; the type is stored on the employee object in Assets, so IT can apply a shorter loan period for externals.
  • An employee can be split over several cost centres in Personio. In Assets the cost centre with the largest share counts, so hardware belongs to one cost centre in reporting.
  • Someone can have several employments in Personio, for example after an extension. KoppelHet uses the most recent employment for start and end date, so an extension does not lead to portal access being revoked.

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, architecture and compliance

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.

Price indication · Basic

Leave your work email and you see the price indication right away.

We only use your address to follow up on your question about this integration.

Frequently asked questions

Can we also have tickets created for onboarding and offboarding?

Yes. By default KoppelHet creates a request of your onboarding request type four weeks before the start date, on behalf of the new employee, and an offboarding request one week before the end date. Externals can get their own request type.

When does IT see a new colleague?

As soon as HR records the employee in Personio and onboarding begins, often weeks before the first working day.

Do externals also get a portal account?

That is up to you. The type from Personio is stored in Assets, and per type we agree whether a portal account is created.

What happens when a contract is extended?

KoppelHet then uses the new employment, and portal access simply stays.

What about the GDPR?

You are the controller and KoppelHet is the processor, under a data processing agreement. The integration only reads person and employment data in Personio, and every action is in the audit logging.

Technical details for IT

For those who want to know how it works under the hood: APIs, fields and sources used.

  • Personio is read through webhooks (Person.created, Person.updated, Employment.updated) and the Personio API v2 (persons and employments, most recent first), with a periodic comparison. Fields include org_units, office, supervisor, cost_centers, employment_start_date, employment_end_date, status ONBOARDING and type INTERNAL or EXTERNAL.
  • 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. Assets through the import source API with the scope import:import-configuration:cmdb.
  • Requests through POST /rest/servicedeskapi/request with serviceDeskId, requestTypeId and requestFieldValues (including summary, start date and custom fields), and raiseOnBehalfOf with the accountId of the customer the integration created. KoppelHet fetches the fields per request type through GET /rest/servicedeskapi/servicedesk/{serviceDeskId}/requesttype/{requestTypeId}/field. A comment on an open request through POST /rest/servicedeskapi/request/{issueIdOrKey}/comment.

Which fields are transferred

The key fields. The full mapping is agreed per customer.

Field in PersonioField in Jira Service ManagementNotes
Personio-id van de persoonAssets: medewerkernummer (sleutel)
Voornaam en achternaamKlant: displayName
Zakelijk e-mailadresKlant: email
org_units (type afdeling)Organisatie, met het Personio-id als eigenschap
officeAssets: vestiging
supervisorAssets: manager (verwijzing)
cost_centers (hoogste aandeel)Assets: kostenplaats
Type (INTERNAL of EXTERNAL)Assets: soort medewerker
employment_start_date en employment_end_dateAssets: start, einde en status
Indiensttreding, wijziging of vertrekrequestTypeIdRequest type for onboarding, change or offboarding
Klant die de koppeling aanmaakteraiseOnBehalfOf (accountId)The request is in the employee's name
employment_start_date of employment_end_daterequestFieldValues: startdatum of laatste werkdag
Functie en leidinggevenderequestFieldValues: functie en manager
Afdeling of locatieServicedesk en queue van het request type

Related

Which systems do you want to connect?

Tell us which systems you use and what should happen automatically. Together we define the smallest working solution, with a clear design and a quote before building.