​

Configuring Jira as a Source

​

1. Add account access

• API token: The token used to authenticate against Jira. For instructions on generating it, check Atlassian’s guide.
• User email: The email address associated with the API token.
• Workspace domain: Your Jira domain, without https:// (for example, company.atlassian.net).
• Start date: Optional. The earliest timestamp used for incremental extraction. If left empty, all available history will be fetched.
• Project keys: Optional list of project keys to scope extraction. When defined, project-dependent streams are filtered to those projects.
• Issues stream JQL query: Optional custom JQL filter for the issues stream. It is combined with the start date filter and project filter.

​

2. Select streams

Tip: The stream can be found more easily by typing its name.

​

3. Configure data streams

• Layer: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
• Folder: a folder can be created inside the selected layer to group all tables being created from this new data source.
• Table name: we suggest a name, but feel free to customize it. You have the option to add a prefix to all tables at once and make this process faster!
• Sync Type: you can choose between INCREMENTAL and FULL_TABLE.
  • Incremental: every time the extraction happens, we’ll get only the new data - which is good if, for example, you want to keep every record ever fetched.
  • Full table: every time the extraction happens, we’ll get the current state of the data - which is good if, for example, you don’t want to have deleted data in your catalog.

​

4. Configure data source

• Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource here.
• Determine when to execute an Additional Full Sync. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while.

​

5. Check your new source

​

Streams and Fields

​

Data Model

​

Transformation example: extracting fields from JSON

SELECT
   id,
   key,
   json_extract_scalar(fields, '$.summary') AS summary,
   json_extract_scalar(fields, '$.status.name') AS status_name,
   json_extract_scalar(fields, '$.project.key') AS project_key,
   json_extract_scalar(fields, '$.assignee.account_id') AS assignee_account_id,
   json_extract_scalar(fields, '$.issuetype.name') AS issue_type,
   CAST(json_extract_scalar(fields, '$.created') AS TIMESTAMP) AS created_at,
   CAST(json_extract_scalar(fields, '$.updated') AS TIMESTAMP) AS updated_at
FROM
   nekt_raw.jira_issues

SELECT
   id,
   key,
   JSON_VALUE(fields, '$.summary') AS summary,
   JSON_VALUE(fields, '$.status.name') AS status_name,
   JSON_VALUE(fields, '$.project.key') AS project_key,
   JSON_VALUE(fields, '$.assignee.account_id') AS assignee_account_id,
   JSON_VALUE(fields, '$.issuetype.name') AS issue_type,
   CAST(JSON_VALUE(fields, '$.created') AS TIMESTAMP) AS created_at,
   CAST(JSON_VALUE(fields, '$.updated') AS TIMESTAMP) AS updated_at
FROM
   `nekt_raw.jira_issues`

​

Implementation Notes

​

Filtering behavior

• project_keys limits project-scoped extraction to specific Jira projects.
• issues applies an updated >= start_date filter if a starting timestamp is available, and can additionally apply a custom JQL query.
• The final JQL for issues combines the start date (if present), optional project keys, and optional custom JQL with logical and.
• The Jira /search/jql API endpoint rejects queries that are entirely unbounded. To safely capture all historical records during a full table extraction or the initial run of an incremental extraction (before a state or bookmark is set), the connector automatically falls back to a minimal date bound (updated >= '1900/01/01 00:00'). This ensures all issues are properly synced while keeping the request bounded as required by Jira’s servers.

​

Stream hierarchy behavior

• boards, fields, and issue_types are project-scoped child streams.
• sprints is collected only from scrum boards.
• issue_changelog is collected per issue and includes issue_id as parent context.

​

Skills for agents