Skip to main content

​
What Flow syncs from Jira Service Management

Jira Service Management (JSM) ticket sync links one Flow team inbox to one Jira service desk and request type. Flow imports customer requests by polling and writes updates back when the source direction allows it. Flow does not mirror a whole Jira site. Every Jira Ticket Sync source reads customer requests. A request type named Incident on the Jira side is still a customer request, so Flow reads it through the same request fields as any other request type. The Destination Flow type setting decides whether new imported records become a Flow incident or a Flow request. It does not change which provider fields Flow reads. Jira separates two people on a request:
  • Opened by is the person who filed the request.
  • Requester is the person the request is for.
Flow keeps both on the ticket. For example, an IT manager raises a laptop request on behalf of a new intern. Jira records the manager as the issue creator and the intern as the reporter, and Flow shows the manager under Opened by and the intern under Requester.

​
Prerequisites

Have the Jira Cloud subdomain ready. It is the acme part of https://acme.atlassian.net.

​
Prepare the provider

Jira needs no app installation or custom field work before you connect. Prepare three things on the Jira side:
1

Pick the service desk and request type.

Ticket Sync binds one request type per source. Decide which request type feeds the Flow team inbox first. You can add more sources later, one per request type.
2

Confirm the account can see that request type.

The account you authorize with must be able to open the service desk and the request type in Jira. If it cannot, Flow shows an empty request type list during setup.
3

Decide whether Flow may write back.

A read-only source needs only read access. A source that transitions requests, posts comments, or creates requests from Flow needs write access. Your Jira admin approves both during authorization.

​
Connect in Flow

1

Open Integrations.

As an organization admin, open Integrations and select Add connection.
2

Choose Jira Service Management.

Enter a connection name that identifies its team or purpose. Enter the Jira Cloud site when the authorization flow asks for it.
3

Make the connection available to its teams.

On the Teams step, set Connection available to to the teams that need the connection, or to All teams. The wizard shows this step first, so choose before you authorize.
4

Authorize the connection.

Sign in with the Atlassian account that can access the service desks you need. Approve the requested access.
5

Attach the Atlassian Admin connection.

An organization admin also attaches and verifies the required Atlassian Admin connection.
6

Open the connection's Ticketing tab.

As an organization admin or an eligible team manager, configure ticket sync on this connection. Flow uses its authorized account for discovery and sync.
You can create several JSM connections to the same Jira site. For example, IT and HR can authorize separate accounts with access to their own service desks. Each team manager opens the connection available to their team and configures sources for a team they manage. Add connection creates a separate connection. To update an existing connection’s authorization, use Reauthorize on that connection. Flow enables one Ticketing platform for the organization: JSM or ServiceNow. Several JSM connections and sources can run together. Connecting an account alone does not enable Ticketing.

​
Create a source

A source is one service desk and request type feeding one team inbox. Choose Add source, then work through the setup tabs.
1

On the Source tab, pick the team inbox, service desk, and request type.

Flow reads both lists from Jira, and the description under the service desk shows the Jira project key it resolved. Set Destination Flow type to Incident or Request.If discovery fails or returns nothing, Flow shows manual fields (Manual service desk ID, Manual project key, Manual request type ID, and their name fields) so you can enter the values from Jira yourself.
2

On Sync settings, set the sync direction and ownership.

Set Sync direction to Bidirectional, Flow to provider, or Provider to Flow. Set Ownership to decide which side wins when both changed the same field. Turn on Default create target when new Flow conversations for this team should create a Jira request in this source.
3

On Condition filters, narrow which requests are eligible.

Use Inbound filter. Leave it empty to accept every request of that request type.
4

On Field mappings, map the ticket fields.

Map Subject, Description, Priority, Status, Requester, Opened by, and Assignment team. See Map identity and Clean up subject and description text.
5

On Status mappings, match Jira status names to Flow states.

6

On Priority mappings, match Jira priority names to Flow priorities.

7

Finish setup.

Choose Finalize setup, then confirm the first import for that source.
To change any of this later, open the source and use the same tabs, plus Mapping preview. Saving there uses Save settings.

​
Map identity

Jira sources always show both identity rows on Field mappings. Each row is a picker with a fixed list of Jira fields. Jira sources have no free-text field entry for identity. These defaults match how JSM behaves. When someone raises a request on behalf of another person, JSM rewrites the reporter to the beneficiary and leaves the filer on the issue creator. The customer request response does not return the creator, so Flow reads it from the backing Jira issue and keeps the two people apart. Creator is not offered as a Requester choice. The creator is the filer, not the beneficiary. If you point Requester and Opened by at the same Jira field, Flow warns that both roles use one field and keeps a single person on the ticket. Map Opened by to a different field to keep two people. Worked example. A manager raises “New starter laptop” on behalf of an intern through the Jira portal. Set Destination Flow type to Request and the ticket is a Flow request. Set it to Incident and the same two people appear on a Flow incident.

​
Clean up subject and description text

Text cleanup sits on the Field mappings tab and applies to two fields: Subject and Description. It is one ordered list of changes. Flow runs them top to bottom for the field you selected. Each change has three parts: Truncate adds a Max characters box. The default is 255. Convert to plain text removes HTML and similar markup, which is the usual fix when a Jira description arrives with markup in it.
1

Add a change.

Pick the field at the bottom of the section, then choose Add change. The new step starts as Trim spaces running Both ways.
2

Set the change and direction.

Choose the change, then choose whether it runs when a request syncs into Flow (Inbound), when Flow writes the field back (Outbound), or both.
3

Order the steps.

Use Up and Down to set the order within a field. Use Remove to delete a step.
4

Read the summary.

Flow prints a plain sentence under the list for each field, so you can confirm the order without rereading every row.
A common Jira setup is Convert to plain text on Description running Inbound, then Trim spaces running Both ways. Add Truncate on Subject running Outbound so long Flow subjects fit the Jira summary. You can add up to eight changes per field. The same editor appears during source setup and later in source settings, so cleanup you add during setup is the cleanup you edit afterwards.

​
Status mappings

Status mappings matches Jira status names to the six Flow states: Open, In progress, On hold, Resolved, Closed, and Canceled. Enter the Jira status name exactly as Jira shows it. Add more than one Jira status under a Flow state with the plus control. Incoming tickets accept every listed status. When a Flow state lists more than one Jira status, mark one as the outbound default with the check-mark control. The chosen row then reads Current outbound default, and Flow uses it when Flow moves a ticket to that state.

​
Priority mappings

Priority mappings sits next to Status mappings and works the same way. Jira priority values group under four Flow priorities: Urgent, High, Normal, and Low. Enter Jira priority names, such as Highest, High, Medium, or Low. Flow seeds the usual Jira names so most sites need no edits: Highest becomes Urgent, High becomes High, Medium becomes Normal, and Low becomes Low. If your site renamed priorities, replace the seeded names with your own. A site that uses Blocker, Major, Minor, and Trivial lists Blocker under Urgent, Major under High, Minor under Normal, and Trivial under Low.

​
Preview a mapping

Open a configured source and use Mapping preview. Type a sample provider Title, Status, and Priority, then choose Preview mapping. Flow shows the Flow result for each field and lists provider values that have no status or priority row under Unmapped values. Preview does not save mappings or create tickets. Use it to confirm that a renamed Jira status resolves to the Flow state you expect. Also confirm that an unlisted priority appears under Unmapped values instead of mapping to Normal.

​
Imported request form

When a Jira request type collects answers through a portal form, Flow copies those answers onto the ticket as a read-only Imported request form. It keeps the shape of the original form, including plain fields, nested sections, and table answers with more than one row.

​
Capabilities

  • Jira Cloud authorization at the org level, with team-scoped sources
  • One source per service desk and request type, feeding one Flow team inbox
  • Polling-based import of customer requests and their comments
  • Outbound create, comment, and transition when Flow owns the linked record and the direction allows it
  • Separate Opened by and Requester identity on every source
  • Ordered text cleanup on Subject and Description in both directions
  • Status and priority translation with per-priority outbound defaults
  • Read-only imported request form on tickets that came from a portal form
  • Verified Atlassian Admin connection for user matching when profile emails are hidden

​
Automation integration reference

Automation action, scope, and risk reference lives in the Jira Service Management integration. Ticket Sync and automation connections are configured separately. Connecting one does not connect the other.

​
Sync and behavior

  • Flow polls each source on its own schedule. Jira webhooks are not used.
  • Flow syncs the source scope, not the whole site. Requests outside the request type or the inbound filter are never imported.
  • If Jira returns a throttle response, Flow records a provider pause and resumes after the retry window.
  • Flow builds Jira record links from the connected site and trusted record identifiers.
  • Requester-safe views hide provider links, provider identifiers, and diagnostics.

​
Troubleshooting