Jira
Two-way sync Jira issues, statuses, assignees, sprints, and custom fields with Airtable, Notion, Google Sheets, and more. Each Jira project syncs as a table.
Jira Connector Guide
Section titled “Jira Connector Guide”This guide covers how to connect Whalesync to Jira, how your projects and issues appear in Whalesync, and which fields sync.
In Whalesync terms, a Jira Cloud site is the base you pick, each project on it is a table, and each issue in the project is a record. Three more tables, Users, Sprints, and Versions, list what the people, sprint, and version fields point at; they are read only.
Connecting to Jira
Section titled “Connecting to Jira”Whalesync connects by signing in with your Atlassian account, and acts as that Jira user. See Authorize Jira for the sign-in and the Jira permissions the user needs.
- In Whalesync, choose Jira and sign in with Atlassian.
- Pick the Jira site to sync. Every Jira Cloud site the sign-in reaches is listed.
- Pick the projects to sync.
Syncing Data
Section titled “Syncing Data”Every project the connected user can browse in Jira is available as a table. A project's table holds all of its issues, whatever their type, subtasks included, and its Issue type column says which type each one is.
A table's columns are the fields on the project's create screens, across all its issue types, plus the ones every issue has: Key, Link, Status, Status category, Resolution, Reporter, Creator, Subtasks, Time spent, and the created, updated, and resolved times. So two projects with different fields have different columns, and a custom field appears only in projects where it's on a create screen. Reading create screens takes Jira's Create issues permission. In a project where the connected user can't create issues, the table has only Summary, Description, Priority, Assignee, Labels, Components, Fix versions, Due date, and Parent, and none of the project's custom fields.
An issue moved to another project leaves the first project's table and appears in the second's, if that project is synced too. Its Key changes with the move.
Supported Fields
Section titled “Supported Fields”| Jira field | Status | Notes |
|---|---|---|
| Summary | ✅ Supported | Required when creating an issue from another app. |
| Description, Environment | ✅ Supported | Synced as formatted text. See Descriptions. |
| Issue type | ✅ Supported | Set when Whalesync creates an issue: Task when the record names none, or the project's first type that isn't a subtask if it has no Task. Jira changes an existing issue's type by moving the issue, which Whalesync doesn't do, so changing it is reported as a sync issue for that issue. |
| Status | ✅ Supported | A select of the project's statuses. Changed through the project's workflow. See Status changes. |
| Priority | ✅ Supported | Synced by name. |
| Assignee, Reporter | ✅ Supported | Links to the Users table. |
| Labels | ✅ Supported | A multi-select. Jira adds a label the first time an issue uses it. |
| Components | ✅ Supported | A multi-select of the project's components, synced by name. |
| Fix versions, Affects versions | ✅ Supported | Links to the Versions table. |
| Sprint | ✅ Supported | Links to the Sprints table: every sprint the issue has been in. Jira keeps an issue in one open sprint, so Whalesync puts the issue in the last sprint the record lists. |
| Parent | ✅ Supported | A link to another issue in the same project, such as a subtask's parent or an epic. A parent in another project reads as empty. |
| Due date, Start date | ✅ Supported | A date. |
| Story point estimate | ✅ Supported | A number. |
| Original estimate, Remaining estimate | ✅ Supported | In hours, written to Jira in whole minutes. Clearing an estimate leaves Jira's value as it is. |
| Subtasks | ➡️ Supported (1-Way) | Read only. Links to the issue's subtasks. Set a subtask's Parent to change them. |
| Status category | ➡️ Supported (1-Way) | Read only. To Do, In Progress, or Done, from the status. |
| Resolution | ➡️ Supported (1-Way) | Read only. |
| Creator | ➡️ Supported (1-Way) | Read only. A link to the Users table. |
| Time spent | ➡️ Supported (1-Way) | Read only, in hours. |
| Key, Link, Created at, Updated at, Resolved at | ➡️ Supported (1-Way) | Read only. The key, such as PROJ-123, changes when an issue moves to another project. |
| Rank, Team | ➡️ Supported (1-Way) | Read only, as text. |
| Attachments, Comments, Work log, Linked issues, Watchers, Votes | ✖️ Not supported | No column. |
| Development, Vulnerability | ✖️ Not supported | No column. Other apps fill these in. |
Custom fields
Section titled “Custom fields”Each custom field on a project's create screens is a column of that project's table.
| Custom field type | Status | Notes |
|---|---|---|
| Short text, URL | ✅ Supported | |
| Paragraph | ✅ Supported | Synced as formatted text, like Description. |
| Number | ✅ Supported | |
| Date picker | ✅ Supported | A date. |
| Date time picker | ✅ Supported | A date and time, read and written in UTC. |
| Select list (single choice), Radio buttons | ✅ Supported | Synced by option value. The option has to exist in Jira. |
| Select list (multiple choices), Checkboxes | ✅ Supported | Synced by option values. Each option has to exist in Jira. |
| Select list (cascading) | ✅ Supported | A select whose options are each parent and each Parent > Child. |
| Labels | ✅ Supported | A multi-select, like the Labels field. |
| User picker | ✅ Supported | Links to the Users table. |
| Group picker | ✅ Supported | Synced by group name. |
| Version picker | ✅ Supported | Links to the Versions table. |
| Project picker | ✅ Supported | A select of project keys. |
| Text field (read only) | ➡️ Supported (1-Way) | Read only. |
| Other types | ➡️ Supported (1-Way) | Read only, as text. |
Users, Sprints, and Versions
Section titled “Users, Sprints, and Versions”These tables are read only. They're there for the people, sprint, and version fields to link to: to set an issue's assignee from another app, sync the Users table too and link the record to a user in it. See Reference fields.
- Users lists the site's users, including app and customer accounts, with their name, email, account type, and whether they're active.
- Sprints lists the sprints on the site's boards, with their name, state, goal, board, and dates.
- Versions lists every project's versions, with their name, project, description, release and start dates, and whether they're released or archived.
Descriptions
Section titled “Descriptions”Description, Environment, and Paragraph fields are formatted text. Headings, bold, italic, underline, strikethrough, code, subscript, superscript, links, lists, quotes, code blocks, dividers, and tables come through in both directions.
Some of Jira's formatting has no equivalent elsewhere, so it syncs as what it shows. Mentions sync as the person's name, emoji as the character, dates as the day, status lozenges as their text, smart links as plain links, and panels and expands as their contents. Action items sync as list items with their check mark in the text.
Images in a description aren't synced. When a description changes in another app, Whalesync keeps the images the issue has in Jira by adding them at the end.
Status changes
Section titled “Status changes”Jira changes an issue's status through its workflow's transitions, not by editing the field. When a record's Status changes, Whalesync moves the issue through the transition that leads from its current status to the new one.
- If no single transition leads there, the change is reported as a sync issue that names the statuses the issue can move to from where it is, such as Jira can't move PROJ-12 from "To Do" to "Done" in one step. From there it can go to "In Progress". Change the status one step at a time, or change it in Jira.
- If the transition asks for fields, Whalesync fills them in from the record. When a field the transition requires has no value, the sync issue names it. Set the field in Jira, or sync it. For a field Whalesync can't write, such as Resolution, change the status in Jira.
- If the issue's status blocks edits, as Closed often does, and the record changes the status too, Whalesync moves the status first and then makes the edits.
Watcher emails
Section titled “Watcher emails”Synced edits email an issue's watchers unless the connected user is a project admin.
When Whalesync edits an issue's fields, it asks Jira not to email the watchers. Jira honors that only for a user who is an admin of the issue's project. Whalesync doesn't ask for status changes or new issues, which send whatever emails the project's notification scheme sets. To keep synced edits from emailing watchers, connect Jira as a user who is an admin of the projects you sync.
Changes made in Jira
Section titled “Changes made in Jira”Jira doesn't send Whalesync webhooks, so a change made in Jira isn't synced within seconds. Whalesync finds it the next time it checks the project for changes.
Things to Keep in Mind
Section titled “Things to Keep in Mind”- Only projects the connected user can browse are listed.
- Whalesync connects to Jira Cloud. Jira Data Center and Jira Server are not supported.
- Whalesync doesn't create statuses, options, components, versions, or sprints. A value Jira doesn't have is reported as a sync issue for that issue, with Jira's reason, such as Jira rejected the request: …. Labels are the exception.
- A new issue gets Jira's defaults for its empty fields. Whalesync leaves empty fields out when it creates an issue, so Jira fills in the reporter, the priority, and any other default.
- Deleting a record deletes the issue in Jira. Jira refuses to delete an issue that has subtasks until they are deleted, and Whalesync doesn't delete them for you.
- Attachments, comments, work logs, and issue links are not synced, and neither are watchers and votes.
- Whalesync reads about 15,000 issues an hour from each Jira connection, so a large first sync takes a while: about 40 minutes for 10,000 issues.
- Jira limits how many requests Whalesync can make each hour. When the limit is reached, the sync pauses with You have exceeded the service API quota, then starts again by itself within the hour.