Support integration guide
Jira Service Management + UbiGrowth workflows
Jira Service Management is Atlassian's service desk product, owning requests, incidents, and change workflow alongside Jira. This guide covers the records that matter, how the connection should be scoped, and what the first bounded workflow should be.
Introduction
Make Jira Service Management part of the workflow, not another silo.
Validate connector availability for your workspace
This guide covers how a team designs a support workflow around Jira Service Management with UbiGrowth: which records stay authoritative, how the connection should be scoped, what the first bounded workflow should be, and how to tell whether it worked.
The records that matter are Request, Issue, Request Type, Queue, SLA, Customer, and Approval. A Service Management Request is a Jira Issue with a Request Type on top, and customers are portal customers rather than Jira users. A workflow written against the Jira API alone cannot see the portal-facing view the customer has.
Jira Service Management is not currently on UbiVibe's verified connector list. This page is an implementation design reference: use it to specify the workflow, then validate whether the connection is available and correctly scoped for your workspace before you make it a dependency. The verified UbiVibe connections today are Salesforce, HubSpot, Gmail, Google Drive, Slack, and GitHub.
The platform layer is the usual destination for this connection, because the value shows up as governed context and execution shared across more than one team.
Why teams evaluate this connection
Integrations create value when they remove operating friction.
The first design decision is not which API endpoint to call; it is which system owns the record, what event should trigger work, who owns the exception path, and what successful completion means.
Support integrations are usually justified with deflection metrics, which is the wrong starting point. The expensive part of a ticket is not the reply; it is the time an agent spends assembling context from Jira Service Management, the CRM, the product, and the issue tracker before they can write anything useful.
The second cost is escalation. A ticket handed to another team without account context, history, and reproduction detail comes back as a question, and the customer waits through a round trip that added nothing.
You're likely here because
- Agents assemble customer context from several systems before replying
- Escalations arrive at other teams missing the detail they need
- Support tooling improvements never clear the engineering backlog
Record model
What a Jira Service Management integration actually reads and writes.
Integration design starts from the objects the system really exposes, not from a generic connector diagram. These are Jira Service Management's.
Identity and matching
A Service Management Request is a Jira Issue with a Request Type on top, and customers are portal customers rather than Jira users. A workflow written against the Jira API alone cannot see the portal-facing view the customer has.
Start here
Read Requests at risk against an SLA in one Queue and route them with the approval step, if any, that is blocking.
What this will not do
It will not behave like plain Jira. Request Types, portals, and SLAs are a separate layer with its own API surface.
The constraint to plan around
SLA calculations run inside the product against calendars and pause conditions; recomputing them externally will disagree with what the customer sees. Read the SLA field rather than deriving it.
Build notes
What you actually have to reason about in Jira Service Management.
The fields that carry meaning, how the connection authenticates, and whether the event surface can be trusted. This is the part that decides whether the integration works in month three.
| Field | Why it matters |
|---|---|
| requestTypeId | the portal-facing type layered over the underlying Jira issue type |
| SLA field | computed inside the product against calendars and pause conditions — recompute externally and you will disagree with the customer |
| reporter vs requestParticipants | portal customers are not Jira users, so the Jira API alone misses the customer view |
| approval status | a distinct workflow step that can block progress invisibly from the issue status |
| queue | the agent-facing grouping, defined by JQL rather than stored on the issue |
Authentication
Same Atlassian token model as Jira, with Service Management endpoints separate from core Jira ones. Customer-facing operations need the Service Desk API specifically.
Events and delivery
Jira webhooks fire for the underlying issues; SLA and approval changes may not surface as distinct events. Polling the SLA field is often necessary for breach prediction.
Workflow
How the Jira Service Management workflow runs.
The operating sequence, from reading the source system through to the result landing back where it belongs.
Step 01
Pick up the ticket with context
The account, purchase, and prior-conversation context for a Jira Service Management ticket is assembled before the agent starts writing.
Step 02
Triage against real priority
Tickets are grouped by issue type, account context, and age so the queue reflects what matters rather than arrival order.
Step 03
Draft with the human in the loop
A response is drafted from the assembled context and reviewed by the agent, who remains responsible for what the customer receives.
Step 04
Escalate with the history attached
Escalations carry account context, history, and reproduction detail into the receiving system, removing the clarification round trip.
Design decisions
The support decisions this connection forces.
Each of these has to be settled before the Jira Service Management workflow is allowed to write anything.
Step 01
Define the escalation contract
Decide what an escalation leaving Jira Service Management must include — account context, history, reproduction detail — so the receiving team does not have to ask.
Step 02
Keep the customer-facing boundary explicit
Context assembly, triage, and drafting can be automated well before automated replies are appropriate. Treat those as separate decisions.
Implementation path
How to implement the Jira Service Management workflow.
- 01
Pick one high-volume issue type and map exactly which context an agent needs to resolve it.
- 02
Connect Jira Service Management and the systems holding that context, at scopes limited to support use.
- 03
Build a triage or context surface in Launch and test it against recent real tickets rather than samples.
- 04
Once SLA-risk routing works, add request-type analysis so the highest-volume request types get self-service rather than more agents.
Governance
Controls that matter.
Control 01
Customer-facing replies stay under human review; the workflow assembles and drafts rather than autonomously answering.
Control 02
Access exposes the customer context the workflow needs, not the whole account surface.
Control 03
Billing, refund, and account-change actions require explicit human authorization.
Failure modes
How a Jira Service Management integration breaks in production.
Not generic integration advice. These follow from how this system actually behaves, which is why they look nothing like the list on the next guide over.
Symptom 01
Externally computed SLA figures disagree with the customer-facing ones.
Cause
SLAs are computed inside the product against calendars and pause conditions.
Fix
Read the SLA field rather than recomputing, and never present a derived figure to a customer.
Symptom 02
A request appears stalled with no obvious cause.
Cause
An approval step is blocking, invisible from the issue status.
Fix
Read approval state alongside status and surface the pending approver.
Symptom 03
The portal view differs from what the integration sees.
Cause
Portal customers are not Jira users and the core Jira API misses the customer-facing layer.
Fix
Use the Service Desk API for anything customer-facing.
What changes at scale
Tenant rate limits are shared with Jira Software on the same instance. Queue-based reads via JQL scale better than per-request polling.
Examples
What a working Jira Service Management workflow looks like.
Bounded scenarios rather than a feature list. Each one can be verified against work the team already does.
Service desk workflows
With Jira Service Management connected, the account, purchase, and prior-conversation context relevant to a ticket is assembled before the agent starts, instead of across five open tabs.
Triage surface
A Launch-built queue view groups Jira Service Management tickets by issue type, account value, and age — the view the team actually needs, without waiting for engineering capacity.
Limitations and considerations
What to validate before you depend on this.
- SLA calculations run inside the product against calendars and pause conditions; recomputing them externally will disagree with what the customer sees. Read the SLA field rather than deriving it.
- Adding a public comment reaches the requester through the portal and by email. Internal comments are a separate flag, with the same failure mode as every ticketing system here.
- When plain Jira behaviour is assumed. Request types, portals, SLAs, and approvals form a separate layer with its own API and semantics.
- This is not an autonomous customer-facing agent. Replies should stay under human review, particularly where the account or issue carries real consequences.
- Context quality depends on the systems behind Jira Service Management. A stale CRM record produces a confident and wrong summary.
FAQ
Jira Service Management integration questions.
What records does a Jira Service Management integration actually work with?
The primary records are Request, Issue, Request Type, Queue, SLA, Customer, and Approval. A Service Management Request is a Jira Issue with a Request Type on top, and customers are portal customers rather than Jira users. A workflow written against the Jira API alone cannot see the portal-facing view the customer has.
What should the first Jira Service Management workflow be?
Read Requests at risk against an SLA in one Queue and route them with the approval step, if any, that is blocking.
What will a Jira Service Management integration not do?
It will not behave like plain Jira. Request Types, portals, and SLAs are a separate layer with its own API surface.
What is the main constraint to plan around?
SLA calculations run inside the product against calendars and pause conditions; recomputing them externally will disagree with what the customer sees. Read the SLA field rather than deriving it.
What changes about a Jira Service Management integration at scale?
Tenant rate limits are shared with Jira Software on the same instance. Queue-based reads via JQL scale better than per-request polling.
How does authentication work for Jira Service Management?
Same Atlassian token model as Jira, with Service Management endpoints separate from core Jira ones. Customer-facing operations need the Service Desk API specifically.
Does Jira Service Management support webhooks, and can they be trusted?
Jira webhooks fire for the underlying issues; SLA and approval changes may not surface as distinct events. Polling the SLA field is often necessary for breach prediction.
What is the risk of writing to Jira Service Management?
Adding a public comment reaches the requester through the portal and by email. Internal comments are a separate flag, with the same failure mode as every ticketing system here.
When is connecting Jira Service Management the wrong call?
When plain Jira behaviour is assumed. Request types, portals, SLAs, and approvals form a separate layer with its own API and semantics.
What should a Jira Service Management integration automate first?
Start with one bounded workflow that removes a measurable handoff, duplicate-entry step, reporting delay, or follow-up gap. Expand only after the first workflow is reliable.
Does UbiGrowth require Jira Service Management to be replaced?
No. The operating model is designed around connecting to systems that should remain authoritative and building workflows around them rather than forcing a wholesale replacement.
Is connector availability identical for every workspace?
No. Availability can depend on provider configuration, authentication, scopes, workspace setup, and deployment state. Validate the required connection before treating it as an operational dependency.
Does this replace Jira Service Management?
No. Jira Service Management stays the system of record for conversations. The workflow layer sits around it for context assembly, triage, and connected escalation.
Will it reply to customers automatically?
Not by default, and not until the workflow has been proven. Context assembly and drafting are separate decisions from automated sending.
How do escalations improve?
The escalation carries its trigger, account context, and history into the receiving system, which removes the clarification round trip that usually costs the customer another day.
How this access is governed
What ARIA is allowed to do in Jira Service Management, and who decides.
Connecting Jira Service Management is a permission decision, not just a setup step. These are the controls that decide what ARIA can reach, what it can change, what gets recorded, and how you take the access back.
Required permissions
ARIA works through the scopes the connection was granted, and no others. Authorization happens at the provider, so the permissions being requested are shown by the system itself before anything is connected.
What it can reach
Reachable systems are the intersection of what your organization approved in the connector registry and what the requesting identity is permitted to use. Identity resolves before execution, not after.
What it can do
Actions run through explicit execution paths with state, spend, and failure boundaries — a bounded worker path rather than an open-ended agent loop with a credential.
Credential handling
Credentials live in the governed connection layer and are resolved through canonical connection identity. They are not pasted into individual workflows, prompts, or generated artifacts.
Action logging
Execution carries state and traces: what triggered the work, which connection it used, and what came back — including an explicit failure when something did not run.
Approval and revocation
Consequential actions can be made to require a person to approve them. Access can be changed or revoked at the connection, and ARIA loses that reach without unpicking the work already completed.
Start with ARIA
Ask ARIA to run this integration.
Describe the outcome you need across this system. ARIA works out the scopes, data, and actions the job requires, and operates inside the access you grant — which you can change or revoke.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Turn the integration into a working business outcome.
Start with ARIA to describe the outcome, then continue into the product path that fits the workflow. Connector availability and required scopes should be validated for the specific workspace before production use.