> For the complete documentation index, see [llms.txt](https://docs.siit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.siit.io/integrations/ticketing/jira-service-management.md).
# Jira Service Management
### What you get
* **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a JSM service project and request type, and a linked ticket is created with the Siit context pre-filled.
* **Configurable two-way sync.** Choose exactly what cascades between a Siit request and its linked JSM ticket: resolution, assignee, notes, and messages, each opt-in per direction.
* **Escalation defaults per project.** Set the default request type, status, and assignee behavior Siit applies on escalation, overridable at escalation time.
* **Customer Request Type on escalation.** Choose the JSM Customer Request Type from a dedicated picker, the way JSM itself treats it, so tickets land in the right portal queue and route correctly from the start.
* **Workflow-driven ticket creation.** Use **Create JSM ticket** as a workflow step, with field mapping and approval gating where needed.
* **Custom field mapping.** Map Siit form fields and request attributes to your JSM custom fields.
* **Audit trail.** Every JSM action triggered from Siit is recorded on the request timeline.
### When to use Jira vs. Jira Service Management
Both integrations live in the Atlassian ecosystem, but they fit different jobs:
* **Use Jira** when escalating to engineering, product, or platform teams who track work in Jira Software projects (bug fixes, feature requests, project-linked work).
* **Use Jira Service Management** when escalating to specialist ITSM queues (network team, security ops, facilities, advanced IT) who manage incoming requests as JSM tickets.
If both teams use Atlassian, you can connect both integrations and pick the right destination per request.
### How it works
When a Siit request needs specialist attention managed in JSM:
1. From the request side panel, click **Escalate ticket** and pick **Jira Service Management**.
2. Choose the JSM service project, request type, and any required fields. Custom fields configured in **Settings → Integrations → Jira Service Management** appear automatically.
3. Submit. Siit creates the JSM ticket, links it back to the Siit request, and posts the link on both sides.
4. As the JSM ticket progresses, status updates flow back to Siit. Use these as workflow conditions — for example, "when the linked JSM ticket is Resolved, set the Siit request to Resolved."
The same flow is available in workflows (as a **Create JSM ticket** action).
### What syncs from JSM
Sync is set at the integration level and is fully bi-directional. In **Settings → Integrations → Jira Service Management → Settings**, you get one table per direction. Each row is an event, and you choose how Siit reacts.
**From Siit to JSM** controls what happens on the JSM ticket when the Siit request changes: resolve on resolution, match the assignee, push notes, and push new messages, each opt-in or set to do nothing.
**From JSM to Siit** controls what flows back to the request when the JSM ticket changes: resolve the request, match the assignee, import comments, and import notes.
Every option is opt-in, and the choices are capability-aware: Siit only shows behaviors JSM can honor. This also prevents a private note from surfacing as a public comment where the provider has no private-comment concept.
### Custom field mapping
Map Siit data to JSM custom fields so escalated tickets arrive with the right metadata — request ID, requester, service, priority, anything specialist teams need to triage quickly.
Set this up in **Settings → Integrations → Jira Service Management → Field mapping**. For the full setup guide, see [Custom field mapping](https://help.siit.io/custom-field-mapping).
### Before you connect
* A JSM admin (or Jira site admin) to authorize the connection.
* A clear idea of which JSM service project(s) you want to escalate to.
* Optional: a dedicated "Siit Integration" Jira user, so the integration survives admin turnover.
### Connect Jira Service Management
1. In Siit, go to **Settings → Integrations**, find **Jira Service Management** in the Ticketing section, and click **Connect**.
2. Sign in to your Atlassian site as an admin and approve the requested scopes.
3. Pick the JSM service project(s) you want available for escalation.
4. Configure default request type, priority, and field mapping.
5. Test by escalating a sample request from Siit to JSM.
Need a more detailed walkthrough? Reach out to support via the in-app chat — the JSM setup follows the same Atlassian OAuth flow as our Jira integration ([Jira integration setup](https://help.siit.io/jira-integration) is a useful reference).
### After the connection
* **Try the side panel.** From any request, click **Escalate ticket → Jira Service Management** and create a test ticket.
* **Set up status sync rules.** Map JSM statuses to Siit's external ticket statuses (e.g., JSM "Resolved" → Siit "Resolved").
* **Configure field mapping.** Map your Siit fields to the JSM custom fields specialist teams rely on.
* **Build your first workflow.** A common starter: "when tag = 'Network', auto-create a JSM ticket in the Network service project."
### Common workflows
**Network team handoff.** *Trigger: Tag "network" added. Actions: Create JSM ticket in NETWORK service project → Notify requester with the JSM link.*
**Security incident escalation.** *Trigger: Service = "Report security concern". Actions: Create JSM ticket in SEC service project → Set Siit priority to High → Post to #security-ops.*
**Facilities request.** *Trigger: Service = "Office issue". Action: Create JSM ticket in FACILITIES service project, pre-filling the requester's office location from their profile.*
**Auto-resolve on JSM completion.** *Trigger: Linked JSM ticket status = Resolved. Action: Set Siit request to Resolved → Notify requester.*
### Tips
* **Use a dedicated service account** for the JSM connection so it survives individual admin turnover.
* **Map JSM request types thoughtfully.** JSM request types matter for SLA and queue routing on the JSM side — pick the right default for each escalation path.
* **Keep Siit as the employee surface.** Employees stay in Slack, Teams, or the Siit Portal. The JSM ticket is internal — only specialists need to see it.
* **Use status sync to close the loop.** Mapping JSM "Resolved" to Siit "Resolved" keeps requesters informed without manual ticket updates.
### Help Center guides
* [Jira integration setup](https://help.siit.io/jira-integration) — Atlassian setup walkthrough (also covers JSM)
* [Jira fields consumed](https://help.siit.io/jira-fields-consumed) — full field reference (applies to JSM)
* [Custom field mapping](https://help.siit.io/custom-field-mapping) — map Siit data to JSM custom fields
### Troubleshooting
**"Authorization failed" on connect.** The admin signing in lacks Atlassian admin rights, or the site has restricted third-party app installs. Try with a site admin.
**Service project missing from the destination picker.** The Siit Atlassian user lacks Browse Projects permission for that JSM project. Update permissions in JSM and re-sync.
**Request type or Customer Request Type missing.** The integration only surfaces request types the connecting user can create. Check the user's JSM portal access for that service project.
**A service project shows as unreachable.** The project was deleted or archived. Siit flags it in the collections list so escalations don't fail silently.
**Custom field not appearing in mapping.** The field may be tied to a specific request type or screen scheme. Confirm the field is on the request type's create or edit screen, then re-run mapping.
**A sync event isn't cascading.** Check the sync table in **Settings → Integrations → Jira Service Management → Settings**. Events set to "Do nothing" won't cascade, and behaviors JSM can't honor won't appear as options.