> ## Documentation Index
> Fetch the complete documentation index at: https://docs.letsflow.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Jira Service Management

> Connect Jira Service Management ticket sync, keep the filer and the beneficiary apart, and translate text, status, and priority values.

## 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

| You need | Why |
| - | - |
| A Jira Cloud site with Jira Service Management | Ticket Sync reads customer requests from a service desk on that site |
| A Jira admin or service desk admin who can approve the connection | Authorization asks that account to approve Flow access |
| An Atlassian account with access to the service desk you plan to sync | Flow discovers service desks and request types with that account |
| A Flow organization admin | Creates, shares, and reauthorizes connections |
| A Flow team manager with access to the connection | Configures ticket sync for a team they manage |
| A Flow team to receive the tickets | Every source imports into one team inbox |

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:

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Connect in Flow

<Steps>
  <Step title="Open Integrations.">
    As an organization admin, open **Integrations** and select **Add connection**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Authorize the connection.">
    Sign in with the Atlassian account that can access the service desks you need. Approve the requested access.
  </Step>

  <Step title="Attach the Atlassian Admin connection.">
    An organization admin also attaches and verifies the required Atlassian Admin connection.
  </Step>

  <Step title="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.
  </Step>
</Steps>

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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="On Condition filters, narrow which requests are eligible.">
    Use **Inbound filter**. Leave it empty to accept every request of that request type.
  </Step>

  <Step title="On Field mappings, map the ticket fields.">
    Map Subject, Description, Priority, Status, Requester, Opened by, and Assignment team. See [Map identity](#map-identity) and [Clean up subject and description text](#clean-up-subject-and-description-text).
  </Step>

  <Step title="On Status mappings, match Jira status names to Flow states." />

  <Step title="On Priority mappings, match Jira priority names to Flow priorities." />

  <Step title="Finish setup.">
    Choose **Finalize setup**, then confirm the first import for that source.
  </Step>
</Steps>

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.

| Flow row | Jira choices | Default |
| - | - | - |
| **Requester** | Reporter, Request participants, Raised on behalf of | Reporter |
| **Opened by** | Creator, Reporter | Creator |

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.

| What Jira stores | What Flow shows |
| - | - |
| Creator: the manager | Opened by: the manager |
| Reporter: the intern, because JSM rewrote it on a raise-on-behalf-of create | Requester: the intern |

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:

| Part | Values |
| - | - |
| **Field** | Subject, Description |
| **Change** | Trim spaces, Truncate, Convert to plain text |
| **Direction** | Inbound, Outbound, Both ways |

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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Order the steps.">
    Use **Up** and **Down** to set the order within a field. Use **Remove** to delete a step.
  </Step>

  <Step title="Read the summary.">
    Flow prints a plain sentence under the list for each field, so you can confirm the order without rereading every row.
  </Step>
</Steps>

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.

| Behavior | What it means |
| - | - |
| Incoming tickets use every listed value | List each Jira priority name your site actually uses under the Flow priority it belongs to |
| One outbound default per Flow priority | When a Flow priority lists more than one Jira name, the check-mark control picks the one Flow writes back. It then reads **Current outbound default** |
| Unlisted values on existing tickets | A Jira priority you never listed keeps the current Flow priority on a ticket that is already linked |
| First-time import of an unlisted value | A new import with no matching row starts at Normal. Later syncs do not treat that as a mapped translation |

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.

| Behavior | Detail |
| - | - |
| Read only | Flow displays the answers. Edits in Flow do not change the Jira request |
| Refreshed by polling | Answers update when the request changes. **Sync now** rebuilds the full copy |
| Not a Flow catalog item | Importing a request form does not create a Flow catalog item, and Flow does not list Jira request types in the Flow catalog |
| Answers stay in Jira | Flow does not write form answers back to Jira |
| Sensitive answers are hidden | Password, secret, and masked answers do not enter the copy |
| Summary and description are skipped | Those answers already appear as the Flow subject and first message |

## 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](/automations/connectors/jira-service-management). 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

| Symptom | What to check |
| - | - |
| Authorization fails or the window closes early | Confirm the subdomain is the site subdomain only, and that the Atlassian account can approve the requested access. |
| No service desks found | The authorized account cannot see any service desk on that site. Grant it access in Jira, then choose **Retry loading service desks**. |
| No request types found | The account can see the desk but not the request type. Grant access in Jira, then choose **Retry loading request types**. |
| Requester and Opened by show the same person | The same Jira account filed the request it is for, or both rows point at the same Jira field. Check the two pickers on **Field mappings**. |
| Opened by is empty | The request has no separate creator, or Opened by is mapped to a field this request does not carry. Map it to Creator. |
| A request imports with the wrong Flow state | Add the Jira status name to the correct Flow state on **Status mappings**, then confirm the result on **Mapping preview**. |
| Priority never changes on a linked ticket | The Jira priority name is not listed on **Priority mappings**. Existing tickets keep their current Flow priority. |
| Flow writes the wrong Jira priority back | More than one Jira name sits under that Flow priority. Set the one you want as the outbound default. |
| Descriptions arrive with markup | Add a Convert to plain text change on Description running Inbound. |
| Imported request form is missing | That request type collects no portal answers, or the request predates the form. Flow does not invent a form. |
| Outbound updates never reach Jira | Confirm the source direction allows outbound and that the write access was approved during authorization. Reconnect after changing Jira roles. |
| Too many requests import | Narrow the source with an inbound filter, or use a more specific request type. |

## Related topics

* [Ticketing overview](/integrations/ticketing/overview)
* [ServiceNow ticketing](/integrations/ticketing/servicenow)
* [Jira Service Management automation integration](/automations/connectors/jira-service-management)
* [Troubleshoot connections and sync](/setup/troubleshooting/connections-and-sync)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.