The Jira integration imports structures from Jira into ZEP – from Spaces to Epics to Issues. Jira remains the leading system for the transferred structures. Depending on your needs, Jira Spaces can be mapped to ZEP customers (typical for consulting firms) or to ZEP projects (typical for internal IT teams).

For the setup, you will need:

In ZEP, open Administration > Interfaces > Interface Marketplace. Select Jira and click Add. You will then be guided through the booking process in the self-service tool. After booking, the Jira integration appears in your interface overview and can be configured.

Enter the following credentials in the settings:

Then click Test Connection to verify the connection. The status only switches from “inactive” to “active” when the test is successful.

The core of the integration: using dropdowns in the settings, you define how Jira elements are mapped to ZEP structures. The following table provides an overview:

Jira Spaces correspond to Jira projects. You can have each Space created as a ZEP project or a ZEP customer. When mapped as a customer, the customer number is automatically composed from the configured prefix and the Jira key (e.g. jira_knr_PROJ-1). Spaces that should not be imported can be left on “no mapping”.

Epics are nested under the result of their parent Space. They can be created as a ZEP project or a ZEP task. Since Spaces and Epics cannot both be mapped to ZEP projects at the same time, mapping an Epic to a project is only possible when the parent Space is not also imported as a project.

Issues automatically follow the mapping of their parent Epic: if the Epic was imported as a ZEP project, the Issue is created as a ZEP task. If the Epic was imported as a ZEP task, the Issue is created as a ZEP ticket.

Issues that are not assigned to an Epic in Jira cannot be imported without special configuration. To prevent these from being lost, you can define a default target: a default ZEP project (Issues are created as tasks) or a default ZEP task (Issues are created as tickets). All issues without an Epic — even from different Jira Spaces — then end up in this single default target and may need to be reassigned manually there. Alternatively, issues without an Epic can be skipped.

If issues without an Epic should land in different ZEP projects depending on the Jira Space — for example, helpdesk tickets in a dedicated ZEP project and other issues in another — the following workaround is recommended: Create an Epic in Jira for each desired parent project (for example an Epic named Helpdesk) and attach the respective issues to it. The Epic is then imported as a ZEP project and the subordinate issues are assigned to this project as tasks.

If the parent Epic is not yet present in ZEP at the time of the sync – for example because it was deleted, archived, or falls outside the 12-week lookback window – the Issue is safely skipped and logged as a warning. It is never attached to the wrong parent and the sync continues. ZEP retries the Issue in the next run as soon as the Epic is available – no user action needed.

When importing an issue, the following information is mapped from Jira into ZEP fields. These fields are updated with every synchronization — status, priority, start date, and due date always reflect the current state in Jira. The assignment of creator and assignee is done automatically based on the email address.

For the start date to be transferred cleanly, a custom field with the exact name Start Date must exist in Jira — the integration specifically looks for this field name. If the field does not exist in your Jira configuration or is named differently, the start date is not transferred, and projects, tasks, and tickets receive the date of the synchronization as their start date instead.

When importing an Issue, the integration automatically transfers the associated Jira Worklogs and converts them into attendance entries in ZEP. The activity to which the time entries are posted is configured once in the settings.

ZEP applies the following rules:

The integration synchronizes automatically every hour. The import is incremental: ZEP only fetches data that has changed since the last successful sync — the reference time is the last successful sync minus one week as a safety buffer. A manual synchronization can be triggered at any time via Sync now.

During the initial setup of the integration, a lookback of up to 12 weeks applies: ZEP imports only Epics and issues that were created or updated in Jira within the last 12 weeks. Older structures are not automatically transferred and must, if needed, be updated in Jira (so they fall into the 12-week window) or manually replicated in ZEP. If, after the first sync, fewer Epics or issues appear in ZEP than expected, the 12-week window is usually the reason.

The synchronization runs in a fixed, chained order: Spaces are imported first, then Epics, and finally Issues. Each stage only starts when the previous one has completed successfully. If a stage fails, the dependent steps are aborted – ensuring no partially imported records are created.

Each sync run creates a log entry with the following counters:

A single failed record does not stop the rest of the batch. Missing parent Epics are logged as warnings and retried in the next sync run. There are no automatic retries – the hourly scheduler handles this.

All configurable parameters of the Jira integration at a glance: