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).
Data direction: Jira → ZEP
Product line availability
Note: The Jira integration is available in ZEP Compact and ZEP Professional. It is not included in ZEP Clock.
Prerequisites
For the setup, you will need:
Access to the Interface Marketplace in ZEP
A Jira email address with administrator rights on the Atlassian domain
A Jira API token – created in Atlassian at id.atlassian.com/manage-profile/security/api-tokens (Create API token → copy)
Your company's Atlassian domain (e.g.
company.atlassian.net)
Note: The integration is exclusively compatible with Jira Software (Jira Project Management) from Atlassian – not with other Jira products such as Jira Service Management.
Setting up the integration
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:
Jira Host: Your company's Atlassian domain (e.g.
company.atlassian.net)Username: The email address of the Jira administrator
Password: The Jira API token
Then click Test Connection to verify the connection. The status only switches from “inactive” to “active” when the test is successful.
Configuring data mapping
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 element | Possible mapping in ZEP |
Space (Jira project) | ZEP project, ZEP customer, or no mapping |
Epic | ZEP project, ZEP task, or no mapping |
Issue (with parent Epic) | ZEP task or ZEP ticket (follows the Epic mapping) |
Issue (without parent Epic) | ZEP task, ZEP ticket (fallback), or no mapping |
Note: Spaces and Epics cannot both be mapped to ZEP projects at the same time. If you import Spaces as projects, Epics can only be imported as tasks or with “no mapping”.
Spaces
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
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
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 without a parent Epic
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). Alternatively, such Issues can be skipped.
Parent Epic not yet imported
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.
Information per Jira issue
When importing an issue, the following information is transferred to ZEP, among other things. These fields are updated with every synchronization – status, priority, and due date always reflect the current state in Jira. The assignment of creator and assignee is done automatically based on the email address.
Title or summary of the issue
Status
Priority
Creation date
Last modified date
Due date, if available
Assignment to the parent project or Epic
Assignment of creator and assignee to employees in ZEP
Importing Worklogs as time entries
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:
Employee assignment is done first by email address; if no match is found, by first and last name.
If a Worklog exceeds the employee's daily capacity (standard working hours), the remaining time is transferred to the next working day – so even long bookings are not lost.
ZEP searches for free time slots between 08:00 and 23:59 per day and skips already occupied slots – no duplicate entries are created.
Weekends, public holidays, and absence days are automatically skipped.
Employees who were not employed on the relevant day are skipped.
Closed months are not used for bookings.
If no free slot can be found, the reason is logged and the rest of the import continues.
Tip: Make sure the email addresses of Jira users match those stored for employees in ZEP – this is the most reliable method for automatic assignment.
Synchronization and log
The integration synchronizes automatically every hour. The import is incremental: ZEP only fetches data that has changed since the last successful sync. A one-week safety buffer is applied retroactively, and the lookback period is capped at 12 weeks. A manual synchronization can be triggered at any time via Sync now.
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:
processed: Total number of processed elements
created: Newly created ZEP entries
updated: Updated ZEP entries
skipped: Unchanged elements – no update needed
failed: Failed elements – the reason is noted in the log; the rest of the sync continues
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.
Settings overview
All configurable parameters of the Jira integration at a glance:
Setting | Description |
Jira Host | Company's Atlassian domain (e.g. |
Username | Email address of the Jira administrator |
Password | Jira API token (created in Atlassian account management) |
Spaces → ZEP entity | Project / Customer / No mapping |
Epics → ZEP entity | Project / Task / No mapping |
Issues without Epic → ZEP entity | Task / Ticket / No mapping |
Default project / task (fallback) | Target for Issues without a parent Epic; enter the name of the ZEP project or task |
Customer number prefix | Prepended to the Jira key when creating ZEP customers |
Default department | Department to which newly created ZEP projects are assigned |
Default activity | Activity to which Worklog time entries are posted |
Activate / deactivate entities | Spaces, Epics, and Issues can be switched on or off individually |