May 2022link
We now sync the Affected Services
, Customer Request Type
, and Approvals
fields with a customer request from Jira Service Management (formerly Jira Service Desk). We sync the Affected Services
, Customer Request Type
, and Approvals
fields into the following tables:
APPROVAL
APPROVER
REQUEST
REQUEST_TYPE
SERVICE
See the Jira ERD for more information.
We are gradually rolling out this feature to all existing connectors. When it’s available for your connector, you will see the APPROVAL
, APPROVER
, REQUEST
, REQUEST_TYPE
, and SERVICE
tables on the Schema tab. To fetch data for all issues, re-sync your connector.
NOTE: Previously, we only synced the
name
subfield in theCustomer Request Type
field. We kept this logic for compatibility. See the January 2021 Release Notes for more information.
April 2022link
We now sync issue watchers
to the ISSUE_WATCHER
table. We are gradually rolling out this feature to all existing connectors. Once this feature is available, you will see the ISSUE_WATCHER
table on the Schema tab. To fetch data for all issues, re-sync your connector.
NOTE: We apply this feature both to new issues and existing issues once they are changed. Fivetran does not consider assigning and unassigning issue watchers a change in an existing issue since there is no initial state in an existing issue for us to compare to.
March 2022link
We now sync the following ISSUE
custom field types:
Rank
syncs to your destination as alexorank algorithm
string.Team
syncs to your destination as an integer value. The integer acts a team identifier. We had also added a new table,TEAM
, that contains additional team data.
To learn how we sync custom fields for Jira, see our June 2020 release note.
February 2022link
You can now select Projects in the setup form to sync only their associated issues.
January 2022link
We now sync the goal
field of the sprint to the SPRINT
table.
November 2021link
Now, we store a separate cursor for each project and use it to track updates in project issues. We can now sync all issues regardless of when the connecting user in your Jira instance was granted permissions for the relevant projects. Previously, we had a single cursor for all issues. When the user was granted permissions for a project after the initial sync had completed, we were not able to capture the old issues created before the user was granted permissions.
We now fetch issues in parallel threads, one for each project, which improves the extract time of the connector. We are gradually migrating all existing connectors to this new mode.
October 2021link
You can now specify the Consumer Key in the connector setup form while creating an application link between Fivetran and your Jira installation. Previously, it was impossible to create an application link if the Consumer key we provided was used by another external application in your Jira installation.
September 2021link
We now capture deleted projects using webhooks. We’re gradually rolling out to all existing connectors.
NOTE: We can’t capture projects that were deleted before your Jira connector registered the webhook in your Jira installation.
August 2021link
Now, if your Jira installation returns an HTTP 500 Internal Server error during a sync, we only skip the relevant issue field records from the sync. Previously, the entire sync failed.
June 2021link
We now sync system Jira fields, such as project
andpriority
, 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 have added a new field, is_active
, to the ISSUE_FIELD_HISTORY
and ISSUE_MULTISELECT_HISTORY
tables. The field allows you to assemble the complete current state of an issue without a full table scan.
It is true
for the current issue records and false
for historical issue records. To get values in the is_active
field for all issues, re-sync your connector. We are gradually rolling out this feature to connectors set up after September 10, 2020.
May 2021link
We have added a new column, author_id
, to the ISSUE_FIELD_HISTORY
and ISSUE_MULTISELECT_HISTORY
tables.
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.
April 2021link
Now you can sync the following table groups by checking the relevant group checkbox on the Schema tab of the connector details page:
BOARD
,ISSUE_BOARD
,PROJECT_BOARD
PERMISSION_SCHEME
,PERMISSION
,PERMISSION_HOLDER
SECURITY_SCHEME
,SECURITY_LEVEL
,SECURITY_SCHEME_LEVEL
.
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 key
field.
March 2021link
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:
- The
PERMISSION
,PERMISSION_SCHEME
,PERMISSION_HOLDER
,PROJECT_ROLE
tables - The
permission_scheme_id
column in thePROJECT
table 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
, SECURITY_LEVEL
, and SECURITY_SCHEME_LEVEL
tables in your destination.
February 2021link
We now support the Satisfaction
and Satisfaction date
fields of Jira Service Management (formerly Jira Service Desk).
January 2021link
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).
December 2020link
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 released pre-built, dbt Core-compatible data models for Jira. Find the models in Fivetran’s dbt hub or data models documentation. Learn more about our dbt Core integration in our Transformations for dbt Core documentation*.
* dbt Core is a trademark of dbt Labs, Inc. All rights therein are reserved to dbt Labs, Inc. Fivetran Transformations is not a product or service of or endorsed by dbt Labs, Inc.
We have fixed capturing of array fields such as components
and fixVersions
in the ISSUE_MULTISELECT_HISTORY
table. Now we write null
instead of "0"
for empty values. The value
and _fivetran_id
column values for the relevant records will be updated during the next sync.
November 2020link
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.
October 2020link
We have improved how we sync historical changes for the standard issue array fields components
, fixVersions
, and 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.
September 2020link
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.
August 2020link
We have added a new column, is_public
, to the COMMENT
table.
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 Estimate
field to theISSUE_AGGREGATE_ORIGINAL_ESTIMATE_HISTORY
tableΣ Time Spent
field to theISSUE_AGGREGATE_TIME_SPENT_HISTORY
tableΣ Remaining Estimate
field to theISSUE_AGGREGATE_REMAINING_ESTIMATE_HISTORY
tableΣ Progress
field to theISSUE_AGGREGATE_PROGRESS_HISTORY
table.
We have also improved the mechanism that detects the Jira changelog to avoid syncing values from one field into multiple history tables.
July 2020link
We have changed the styling of the connector name from “JIRA” to “Jira” in the Fivetran dashboard to match Atlassian’s official styling.
June 2020link
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_[FIELD_NAME]_HISTORY
tables.
Now, the 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 ISSUE_FIELD_HISTORY
table.
We sync all values from the array fields and their history items to a single ISSUE_MULTISELECT_HISTORY
table.
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.
May 2020link
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.
March 2020link
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.
January 2020link
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.
September 2019link
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.
August 2019link
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.
July 2019link
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 labeled “Capture deletes”. To enable capturing deletes, toggle the switch.
May 2019link
- We have added the
WORKLOG
table. To sync theWORKLOG
table, create a new connector or re-sync the existing one.
May 2018link
We have dropped the primary key constraint from the value
field in the ISSUE_[FIELD]_HISTORY
and ISSUE_[FIELD]
tables.
April 2018link
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: