Jira
Jira is a bug tracking, issue tracking and project management software.
Features
| Feature Name | Supported | Notes |
|---|---|---|
| Capture deletes | check | FIELD, ISSUE, PERMISSION, PERMISSION_SCHEME, PROJECT, and SPRINT tables. |
| History mode | check | ISSUE_FIELD_HISTORY and ISSUE_MULTISELECT_HISTORY tables for the improved schema, and to the ISSUE_[FIELD_NAME]_HISTORY table for the old schema, respectively. |
| Custom data | check | |
| Data blocking | check | |
| Column hashing | check | |
| Re-sync | check | |
| API configurable | check | API configuration |
| Priority-first sync | ||
| Fivetran data models | check | |
| Private networking | ||
| Authorization via API | check |
Supported deployment models
We support the SaaS Deployment model for the connector.
Setup guide
Follow our step-by-step Jira setup guide to connect Jira with your destination using Fivetran connectors.
Sync overview
Fivetran uses the Jira REST API (Cloud, on-premises) to fetch data from your Jira installation, and webhooks to capture deleted objects (issues, projects).
Historical changes
We capture value changes that occurred between syncs.
The ISSUE_FIELD_HISTORY table stores historical changes for non-array fields, while the ISSUE_MULTISELECT_HISTORY stores historical changes for array fields. When we first sync an issue, we write the initial field values to either of the history tracking tables, depending on the field type. Also, we write the issue creation timestamp to the time column of the relevant history tracking table. Once the field is changed, we write the new field value to the relevant column and the change timestamp to the time column of the relevant history tracking table.
We use historical syncs for our Jira connector. Every time we receive an update for an issue, we historically update all its fields and history items in full. During the sync, we check if any field values have changed in the source, i.e., are different from the current ones in the destination. If we find such field values, we upsert the corresponding records in the destination. This incurs Monthly Active Rows (MAR) regardless of the source change date.
Multiple syncs of the same history record that we receive from Jira within a given month only count as a single MAR.
Issues
Jira Connections use JQL (Jira Query Language) to make incremental updates on issues.
The issue field value can be a primitive value or a complex object with its own fields. In the latter case, the issue table stores the object identifier and the corresponding dimension tables store other object fields.
Issue sync mode
You can select the projects whose associated issues you want to sync:
- If you choose From all projects, the connection syncs the issues from all projects and you can browse through them. The connection syncs new projects once they are available. No additional action on your part is required.
- If you choose From selected projects, the connection only syncs the issues that belong to the projects selected in the setup form.
If you deselect a project, the connection stops syncing its issues. The issue sync mode applies to all Jira connections, whichever schema they use.
Issues sync limitation
Jira does not provide a way to retrieve all archived issues if you don't explicitly request them separately by ID. Due to that limitation, Fivetran does not sync archived issues.
Non-incremental tables
A Jira connection updates the following groups of tables in full once a day:
BOARD,ISSUE_BOARD,PROJECT_BOARDPERMISSION_SCHEME,PERMISSION,PERMISSION_HOLDERSECURITY_SCHEME,SECURITY_LEVEL,SECURITY_SCHEME_LEVEL
You can manage syncing of these tables on the Schema tab of your Fivetran dashboard.
If you select the BOARD group of tables on the Schema tab, Fivetran syncs all boards and related entities that you can access, regardless of the projects you select in the setup form, as well as syncs the SPRINT table in full. The BOARD group of tables does not depend on the selected Issue sync mode and may increase MAR.
General sync limitation
Since Jira does not explicitly provide information on object field value changes, we are only able to update field values that were changed in Jira when the issue endpoint response contains data related to the relevant object. During the sync, we first call the issue endpoint. Then, as next sync steps, we call all the endpoints corresponding to the issue fields contained in the issue endpoint response. Lastly, we update the old values of the relevant issue fields with the new values from the endpoint responses.
For example, let's assume the issue endpoint response contains an issue item with the status field whose value (id) is 123. We then call the status endpoint and, for a status item with id = 123 in the response, the value of the name field is resolved. Later, in Jira, the name of the status with id = 123 is changed to fixed. We are only able to update the value of the name column to fixed in the STATUS destination table once we sync a change in your Jira source that includes an issue with the status field whose id is 123 and the updated name value is fixed.
User data sync limitation
Fivetran may not sync complete data for theemail and username columns because the Jira REST API may not return the corresponding data. Due to their compliance with the GDPR laws, Atlassian restricts the visibility of user personal data based on the user profile privacy settings. Read Atlassian's Deprecation notice and migration guide for more information.
This limitation applies to Jira Cloud installations.
Syncing empty tables and columns
Our Jira connector doesn't support the creation of empty tables in your destination. We create a table in the destination only if we can retrieve the table data from the source. If Jira doesn’t return data for the source table, we don’t create the table in your destination. However, we support the creation of empty columns in your destination tables.
Schema information
This schema applies to Jira connections set up after September 10, 2020.
The FIELD table contains system information about the Jira issue field such as ID, name (as it is displayed in Jira UI), whether it is custom, and whether it is an array field.
The ISSUE table contains values of non-array system fields.
The ISSUE_FIELD_HISTORY table contains custom field values, their historical changes, and historical changes of non-array system fields. See the Historical changes section for details about how we track historical changes.
The ISSUE_MULTISELECT_HISTORY table contains array field values and their historical changes.
The actual field records have the is_active column value set to true. The author_id column stores the identifiers of the users who made changes to a given issue.
This schema applies to Jira connections set up before September 10, 2020.
To zoom, open ERD in new window.
System fields information
Jira system field types mapping
| Jira type | Destination table / primitive type |
|---|---|
| assignee | USER |
| comment | COMMENT |
| components | COMPONENT |
| created | Instant |
| creator | USER |
| description | String |
| duedate | LocalDate |
| fixVersions | VERSION |
| issuetype | ISSUE_TYPE |
| issuekey | String |
| issuelinks | ISSUE_LINK |
| labels | String |
| parent | Integer |
| priority | PRIORITY |
| project | PROJECT |
| resolution | RESOLUTION |
| security | SECURITY_LEVEL |
| status | STATUS |
| statusCategory | STATUS_CATEGORY |
| subtasks | Integer |
| summary | String |
| updated | Instant |
| versions | VERSION |
| watches | ISSUE_WATCHER |
| worklog | WORKLOG |
Custom fields information
Jira custom field types mapping
| Jira type | Destination table / Primitive type |
|---|---|
| com.atlassian.jira.plugin.system.customfieldtypes:select | FIELD_OPTION |
| com.atlassian.jira.plugin.system.customfieldtypes:multicheckboxes | FIELD_OPTION |
| com.atlassian.jira.plugin.system.customfieldtypes:multiselect | FIELD_OPTION |
| com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons | FIELD_OPTION |
| com.atlassian.jira.plugin.system.customfieldtypes:cascadingselect | FIELD_OPTION |
| com.deiser.jira.profields:profields.customfield.type.list | FIELD_OPTION |
| com.pyxis.greenhopper.jira:gh-epic-link | EPIC |
| com.pyxis.greenhopper.jira:gh-sprint | SPRINT |
| com.atlassian.jpo:jpo-custom-field-parent | ISSUE |
| com.onresolve.jira.groovy.groovyrunner:single-issue-picker-cf | ISSUE |
| com.onresolve.jira.groovy.groovyrunner:multiple-issue-picker-cf | ISSUE |
| com.atlassian.jira.plugins.jira-development-integration-plugin:devsummarycf | String |
| com.atlassian.jira.plugin.system.customfieldtypes:labels | String |
| com.atlassian.teams:rm-teams-custom-field-team | TEAM |
| com.pyxis.greenhopper.jira:gh-lexo-rank | String |
The value of each level of the cascading select field is represented as a single entry in the FIELD_OPTION table. The child value entry contains a link to the parent value in the parent_id column.
Jira Service Management (formerly Jira Service Desk) custom field types mapping
| Jira type | Destination table / Primitive type |
|---|---|
| com.atlassian.servicedesk:sd-customer-organizations | ORGANIZATION |
| com.atlassian.servicedesk:sd-sla-field | SLA |
| com.atlassian.servicedesk:sd-request-feedback-date | DateTime |
| com.atlassian.servicedesk:sd-request-feedback | Integer |
| com.atlassian.servicedesk:vp-origin | REQUEST_TYPE |
| com.atlassian.jira.plugins.service-entity:service-entity-field-cftype | SERVICE |
| com.atlassian.servicedesk.approvals-plugin:sd-approvals | APPROVAL |
Other fields
This feature is available in all Jira connections set up after April 1, 2024.
Besides the field types mentioned in the tables above, which are defined in our internal model, our Jira connector parses each field value from the JSON representation in the following manner:
- If the field value is represented with a primitive value, such as
StringandDateTime, we write it directly either to theISSUE_FIELD_HISTORYorISSUE_MULTISELECT_HISTORYtable, depending on whether the field is array or non-array. - If the field value is represented with a complex object, we extract its unique identifier, write it to the
ISSUE_FIELD_HISTORYorISSUE_MULTISELECT_HISTORYtable, and then write the rest of the properties to a separate corresponding table. The unique identifier can be the object'sid, or the generated_fivetran_idif the object does not contain anidproperty. The table name is stored in thedimension_tablecolumn of theFIELDtable and can be queried byfield_id.
If the dimension_table column has a null value, either the value is a primitive or we have not received any value from your Jira instance yet.
API endpoints
Click External Link in a table header in the ERD to navigate to the Jira API documentation section that describes the corresponding endpoint.
Custom fields warning log
If your Jira object contains a custom field that we don't support, you will see the skip_processing_field Warning during the initial sync.
Custom field feature request
If you don't see a custom field you'd like to sync listed, reach out to our Support Team.