Sympa logoJira Service Management logo

HR to ITSM

Sympa to Jira Service Management integration: customers per organisation unit and requests on joining and leaving

With an integration between Sympa and Jira Service Management, every employee from Sympa becomes a customer in your service desk, in the organisation of their organisation unit, and KoppelHet creates an onboarding request as soon as a start date is set in Sympa. An end date in Sympa produces an offboarding request, and after that day KoppelHet revokes portal access.

What the integration does

Organisations that use Sympa for HR and Jira Service Management as their IT service desk often create customers and organisations by hand. The organisation tree from Sympa does not fit the flat list of organisations in Jira by itself, and a leaver keeps access to the portal.

  1. Every fifteen minutes KoppelHet requests the changed data cards through its own Sympa interface.
  2. KoppelHet creates or finds the customer by work email and adds them to the organisation of their unit.
  3. On a new start date KoppelHet creates the onboarding request on behalf of the manager.
  4. On an end date the offboarding request follows; after that day KoppelHet revokes portal access.
Sympa → KoppelHet → Jira Service ManagementSOURCESympaTARGETJira Service ManagementKoppelHetmapping · logging · monitoringSympa → KoppelHet → Jira Service ManagementSOURCESympaTARGETJira Service ManagementKoppelHetmapping · logging · monitoring
Out: Customer with work email and display name · Organisation per organisation unit, with the Sympa ID as a property · Onboarding and offboarding request on behalf of the manager

What to watch for with Sympa and Jira Service Management

  • Organisation units in Sympa form a tree, and two units can have the same name, such as Purchasing under two business units. Jira Service Management returns the existing organisation for an existing name. KoppelHet therefore puts the parent unit in the name, so the two do not merge.
  • An organisation in Jira Service Management can have properties that are only visible through the API. KoppelHet stores the ID of the Sympa unit there, so a renamed unit in Sympa updates the existing organisation instead of creating a new one.
  • Sympa allows one hundred requests per hour per interface by default, for all methods together. KoppelHet only uses the interface for reading, and requests only changed data cards per run, so there is room within the hour for a nightly comparison of all employees.
  • Read queries to Sympa come from a reporting database, where a change can become visible up to thirty minutes later. KoppelHet lets the window of each run look back half an hour, so an end date that was just entered does not fall between two runs.
  • Sympa can return the manager's email address for the manager field. KoppelHet uses it to raise the onboarding request on behalf of the manager, with an integration account that is an agent, because users with customer permission only may not raise on behalf of someone else.
  • Organisation rows with validity can be requested in Sympa as they apply on a date. A transfer per the first of next month only moves the customer to the other organisation on that day, so until then they keep seeing the requests of their old department.

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 the request number go back to Sympa?

Yes, if the Sympa administrator opens an interface for PATCH on a dedicated field. That is outside this integration and can be added later as an extension.

Technical details for IT

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

  • Sympa through the Sympa Integration API (OData v4) on its own GET-only interface, X-ApiKey or basic authentication; $filter on modified, $top and $skip, at, since and until, and target fields on the manager's data card field. By default 100 requests per hour per interface; reads from the reporting database with a delay of up to 30 minutes.
  • Jira Service Management through /rest/servicedeskapi/: POST customer (Jira administrator permission), POST organization (returns the existing one for the same name), POST organization/{id}/user, PUT organization/{id}/property/{key} (up to 32,768 bytes), POST request with serviceDeskId, requestTypeId, requestFieldValues and raiseOnBehalfOf, and PUT customer/user/{accountId}/revoke-portal-only-access (site administration).

Which fields are transferred

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

Field in SympaField in Jira Service ManagementNotes
Personeelsnummer (uniek identificatieveld)Verzoekveld personeelsnummer en sleutel bij KoppelHet
Voornaam en achternaamdisplayName
Werkadresemail
Organisatie-eenheid met bovenliggende eenheidorganizationSympa ID as a property
Leidinggevende, doelveld e-mailadresraiseOnBehalfOf
Functie en locatierequestFieldValues
Begindatum dienstverbandRequest type onboarding
Einddatum dienstverbandRequest type offboarding, daarna revoke-portal-only-access

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.