Last updated: November 2026
To integrate TOPdesk with Jira, you connect the TOPdesk REST API and the Jira REST API through an integration layer such as ZigiOps, the no-code integration platform by ZigiWave, define which TOPdesk incidents should be escalated to Jira (usually second-line calls assigned to a development operator group), map a minimal set of fields, store a reference on both records, and sync status updates and progress notes back to TOPdesk. Because TOPdesk is widely used in European public sector, education and healthcare organizations, the integration should be designed around data minimisation: send developers what they need to fix the problem, not the caller's personal data.
TOPdesk is a common service management tool across the Netherlands, Belgium, the Nordics, Germany and the UK, especially in municipalities, universities, schools and hospitals. Many of those organizations also run software development teams, internal or outsourced, that work in Jira. When a service desk operator finds that an incident is caused by a bug in an in-house application, the work has to cross from one tool to another. This guide explains how to design that bridge, with a GDPR-aware checklist and a field-mapping table you can adapt.
Without an integration, escalation between TOPdesk and Jira usually works like this: an operator emails a developer or creates a Jira issue by hand, copies the description, and adds the Jira key to the TOPdesk incident in a free-text field. Then the operator has to keep checking Jira to update the caller. The problems are predictable:
An integration replaces the copy and paste with rules: which incidents go to Jira, which fields travel, and which updates come back.
There are three broad ways to connect the two tools.
| Approach | How it works | Good fit when | Watch out for |
|---|---|---|---|
| TOPdesk action sequences or webhooks | TOPdesk calls the Jira API when an incident meets a condition | You only need to create Jira issues, one way, with a few fields | Updates from Jira back to TOPdesk need a separate mechanism; error handling is limited |
| Custom integration on both REST APIs | A script or service polls or receives events from both tools and writes changes across | You have developers to build and maintain it, and requirements are stable | Ongoing maintenance, credential handling, logging and API changes become your responsibility |
| No-code integration platform such as ZigiOps | A configured connector handles both directions, mapping, retries and logging | You want bidirectional sync without writing code, or have several systems to connect | Check that the tool has a TOPdesk connector (not all do), where it runs and whether it stores data |
ZigiOps has ready-made connectors for both TOPdesk and Jira, so this pattern can be configured in a guided UI instead of scripted. Other ITSM-focused platforms, such as ONEiO, also cover TOPdesk. Whatever you choose, the design decisions below stay the same, and the steps below show how each one looks in practice.
Start with the business rule, not the technology. Typical rules are:
Using operator group assignment as the trigger is usually the cleanest, because it matches how TOPdesk already routes work. First-line calls that are resolved at the desk should never reach Jira.
In TOPdesk, create a dedicated operator account for the integration and generate an application password for API access. Give the account only the permissions it needs, for example reading and updating incidents for the relevant operator groups. In Jira, create a dedicated account with permission to browse, create, edit and comment in the target project. For Jira Cloud, use an API token; for Jira Data Center, use the authentication method your security team approves.
Store the TOPdesk incident number in a Jira custom field, for example "TOPdesk Number", and store the Jira issue key in a TOPdesk optional field or external number field on the incident. This reference prevents duplicate Jira issues if the integration retries, and lets operators and developers find the matching record quickly.
How this works in ZigiOps: ZigiOps stores the ID of one record in a field of the other, for example the Jira key in a TOPdesk optional field, and uses it as the correlation between the pair. Every later update reaches the right record, and a retry never creates a second Jira issue.
This is where TOPdesk integrations differ from many others. Service desk records often contain personal data about callers, and sometimes about patients, students or citizens. Developers rarely need any of it.
| TOPdesk incident | Jira issue | Direction | Data protection note |
|---|---|---|---|
| Brief description | Summary | TOPdesk to Jira | Ask operators not to put names in the brief description |
| Request (description) | Description | TOPdesk to Jira | Consider filtering email addresses and phone numbers with a pattern rule |
| Category and subcategory | Component or Label | TOPdesk to Jira | No personal data |
| Object or asset (application) | Component or custom field | TOPdesk to Jira | No personal data |
| Priority (from impact and urgency) | Priority | TOPdesk to Jira | No personal data |
| Caller name, email, phone, department | Not synced | None | Keep in TOPdesk; developers contact the operator, not the caller |
| Attachments | Attachments | Optional | Screenshots may show personal data; sync only on operator approval |
| Processing status | Status | Jira to TOPdesk | No personal data |
| Action (progress notes) | Comments | Both, filtered | Sync only notes marked for the other team; keep invisible-for-caller rules |
How this works in ZigiOps: In ZigiOps, the mapping above is configured field by field in the UI. Caller fields are simply left out of the mapping, and conditional mapping and expressions can strip patterns such as email addresses or phone numbers from the description before it leaves TOPdesk.
TOPdesk processing statuses are configured per organization, and Jira workflows vary per project, so there is no universal mapping. A simple and robust pattern is:
Letting the service desk, not the integration, close the incident keeps the operator in control of communication with the caller and respects the TOPdesk process your organization already uses. In ZigiOps, each of these rules is a trigger condition plus a status mapping in the update flow from Jira to TOPdesk, with no scripts on either side.
For European public-sector bodies this question is often decisive. Ask:
Document the answers in your record of processing activities and, if needed, in a data protection impact assessment. If an external supplier hosts the Jira instance, check that your data processing agreement covers the data you plan to send.
How this works in ZigiOps: ZigiOps does not store the transferred data, is ISO 27001 certified and can run in the cloud or on your own infrastructure, which makes the data protection questions above easier to answer for public-sector buyers.
Use a TOPdesk test environment and a Jira test project. Test these cases before going live:
Pilot with one operator group and one development team for a few weeks before rolling out more widely.
Data protection rules apply whatever tool you use. This checklist is general guidance, not legal advice; involve your data protection officer.
Sending all incidents to Jira floods developers with password resets and printer problems. Use an explicit trigger.
A resolved Jira issue does not always mean the caller's problem is solved. Return the incident to the operator for confirmation.
TOPdesk distinguishes between actions visible to the caller and internal ones. Keep that distinction when syncing Jira comments, or a developer's technical note may end up in an email to a citizen or student.
Many TOPdesk customers outsource application development. If the Jira instance belongs to the supplier, agree who owns the integration, who pays for changes and what happens when the contract ends.
TOPdesk provides a REST API and features such as action sequences that can call external systems, which can be used to create Jira issues. Full bidirectional sync usually needs a custom integration or a third-party integration platform with a TOPdesk connector.
Use an integration platform that offers connectors for both TOPdesk and Jira, such as ZigiOps. You configure triggers, field mappings and status rules in its interface instead of writing scripts. Check that the platform supports your TOPdesk deployment and meets your data location requirements.
Yes. ZigiOps connects to TOPdesk and Jira through their APIs and syncs incidents, statuses, progress notes and attachments in both directions, based on the mapping and conditions you configure. Everything is set up in a no-code UI.
Usually second-line incidents assigned to a development or supplier operator group, or incidents categorised as software defects. First-line calls resolved at the service desk should stay in TOPdesk.
Yes, they can be synced as actions on the incident. Decide whether they should be visible to the caller or kept internal, and filter accordingly.
It can be, if you minimise the personal data transferred, control access, know where data is processed and stored, and have the right agreements in place. Compliance depends on your design and contracts, not on the tool alone.
Yes. The same pattern applies to problem and change records, for example sending a problem with a known software root cause to Jira as a bug. Start with incidents, then extend.