Now we sync system Jira fields, such as
priority, etc., even if there are custom fields with the same names.
Previously, we skipped all fields that had the same names.
This feature applies to connectors set up before September 10, 2020. Connectors created after this date sync all fields regardless of the names.
We added a new field,
is_active, to the
ISSUE_MULTISELECT_HISTORY tables. It allows to assemble the complete current state of an issue without a full table scan.
true for the current issue records and
false for historical issue records. To get values of
is_active field for all of the issues, re-sync your connector. We are gradually rolling out this feature to connectors set up after September 10, 2020.
We have added a new column,
author_id, to the
This column stores the identifiers of the users who made changes to a given Jira issue. This feature applies to all connectors set up after September 10, 2020. Re-sync your existing connector to sync this data for all historical changes.
Now you can sync the following table groups by checking the relevant group checkbox on the Schema tab of the connector details page:
NOTE: When sync is enabled for any of these groups, all tables within the selected groups are re-synced once a day.
Now we sync the historical changes of the
We now sync entries related to Jira permissions. We are gradually rolling out this feature to all existing customers. Once this feature is available for your connector, you will see the following items in your destination:
permission_scheme_idcolumn in the
PROJECTtable See Jira Schema Information section for details.
We have added a new column,
_fivetran_deleted, to the
FIELD table. Now we capture custom fields deleted from source.
We now sync the
Security Level field.
We now sync Issue Security Schemes.
We are gradually rolling out this feature to all existing customers.
Once this feature is available for your connector, you will see the
SECURITY_SCHEME_LEVEL tables in your destination.
We now support the
Satisfaction date fields of Jira Service Management (formerly Jira Service Desk).
We now use the
X-Force-Accept-Language header to get responses in English. This applies to all Jira connectors created after February 1, 2021.
We now support the
name subfield in the
Customer Request Type field of Jira Service Management (formerly Jira Service Desk).
We now automatically capture deletes for Jira connectors. We have removed the “Capture deletes” toggle from the connector setup form. To be able to capture deletes, you must have the Jira Administrators global permission. We cannot capture deleted issues that were deleted before sync deletes was enabled. To get all deleted issues, re-sync your connector.
We have fixed capturing of array fields such as
fixVersions in the
ISSUE_MULTISELECT_HISTORY table. Now we write
null instead of
"0" for empty values. The
_fivetran_id column values for the relevant records will be updated during the next sync.
We now fully support the cascading select fields in Jira issues. We’ve added a new
parent_id column, which refers to the parent value, to the
FIELD_OPTION table. To sync fields of this type for all issues, re-sync your connector.
We have improved how we sync historical changes for the standard issue array fields
versions. We now write the actual values for each historical change, making the table much easier to use. The Jira API delivers empty values if part of the value is removed, and previously we just wrote that empty value.
We now support the Jira Service Management (formerly Jira Service Desk) Organization fields in Jira issues. To sync fields of this type for all issues, re-sync your connector.
We enable the improved schema by default for connectors set up after September 10, 2020. See our June 2020 release note for details about the improvements, which were previously opt-in, but are now default.
We have added a new column,
is_public, to the
We have improved the mechanism that detects similar fields that might cause data integrity issues. When we detect that similar field names would become duplicate names after normalization, we do not sync them to your destination. Instead, we show a warning on your dashboard and ask you to rename the fields. This prevents duplicates in the destination and avoids writing the values of the different fields into the same history table.
To prevent data integrity issues, we will sync some standard fields in the following way:
Σ Original Estimatefield to the
Σ Time Spentfield to the
Σ Remaining Estimatefield to the
Σ Progressfield to the
We have also improved the mechanism that detects the Jira changelog to avoid syncing values from one field into multiple history tables.
We have changed the styling of the connector name from “JIRA” to “Jira” in the Fivetran dashboard to match Atlassian’s official styling.
We have added a new way to sync issue field values and their historical changes. Previously, customers whose
ISSUE table had a large number of fields found that it was generating an overwhelming amount of
ISSUE table contains only columns for the Jira standard fields.
We added a
FIELD table that contains information about all fields.
We sync all values from the custom non-array fields and their history items to a single
We sync all values from the array fields and their history items to a single
We sync initial null values from history items to the history tables to provide a better historical analysis.
If you would like to use this new method, contact our support team to enable it. Then, create a new connector or re-sync the existing one.
We have improved the mechanism that detects the changelog. Now, if a
fieldId is not present in the Jira response, we will find the changelog entries using a
fieldname. This improvement prevents data integrity issues when the current field value is written into the history table as initial.
You can now configure your Jira connector using the Fivetran REST API. This feature is in BETA and available only for Standard and Enterprise accounts.
Previously, when there were multiple changes in the source during the sync, our connector sometimes missed some data. We have fixed this problem by changing our pagination strategy. To ensure that all your data is synced, re-sync your connector.
When the value of a field was null, our Jira connector didn’t always update array values. That meant that, for example, if the value was removed from a field in the source, sometimes the destination still showed the previous value. Now when a field value is null, our Jira connector will write a default empty value according to the type of the field.
Our Jira connector can now sync issues from January 1, 1970 forward. Previously, our connector only synced issues from January 1, 2002 forward. If you have issues from 1970-2002, perform a re-sync to ensure that we capture all issues.
We can now sync empty array type fields, such as
labels. This means that any removed values will be accurately reflected in the destination. Previously, we could not sync array fields with null values, which meant that some values deleted in the source were not deleted in the destination.
We now track deletes in the
WORKLOG table. This means that any deleted work logs will be accurately reflected in the destination.
We now support SLA fields in Jira issues. We are gradually rolling out this feature to all our customers.
When it’s available for your connector, you will see an additional
sla table in your destination.
You can see the
SLA table on our Jira ERD.
To sync all SLA fields, resync your connector.
We now support capturing deleted issues by using webhooks. We are gradually rolling out this feature to all our customers. When it’s available for your account, you will see a switch on the Jira connector setup form labelled “Capture deletes”. To enable capturing deletes, toggle the switch.
- We have added the
WORKLOGtable. To sync the
WORKLOGtable, create a new connector or re-sync the existing one.
We have dropped the primary key constraint from the
value field in the
We now remove the relationship between an issue and an issue label if the issue is removed in Jira.
If you deploy your Jira to a custom root path, you can now specify that path in our setup form: