Jira Service Management, commonly called JSM, is Atlassian’s service management platform for managing service requests, incidents, changes, problems, assets, knowledge, and operational workflows.
It gives teams a structured way to receive requests, route work, manage service levels, respond to incidents, control changes, and measure service performance.
JSM is designed to connect service teams with development and operations teams through the wider Atlassian ecosystem. That makes it particularly useful for organizations that already use Jira Software, Confluence, Bitbucket, or other Atlassian products.
In 2026, JSM also extended into AI-assisted service operations through Rovo and Atlassian Intelligence. Current capabilities include AI-supported request handling, virtual service agents, natural language automation, work item summaries, knowledge assistance, customer sentiment, and incident related intelligence. Availability depends on the plan and feature.
The important point is that JSM is not simply a replacement for an email-based helpdesk.
Used properly, it becomes a service operating layer connecting people, workflows, knowledge, development, operations, and increasingly AI.
Key Highlights: What Is Jira Service Management? Jira Service Management is a service management platform for requests, incidents, changes, problems, assets, and service operations. Jira Service Desk was the earlier product name. JSM expanded the scope into broader ITSM and service management. Jira Software focuses primarily on software development and delivery, while JSM focuses on service delivery and operational workflows. JSM can connect incidents and service requests with development work, deployments, changes, knowledge, and production operations. Core JSM capabilities include request management, customer portals, incident management, change management, problem management, asset management, SLAs, automation, and knowledge management. JSM AI capabilities can assist with request deflection, triage, knowledge, work item summaries, automation, customer sentiment, and incident response. Non-IT teams such as HR, legal, facilities, and business operations can use JSM for structured service workflows. Successful JSM implementation depends on service design, workflow discipline, adoption, knowledge quality, and governance, not simply platform configuration. JSM maturity can progress from basic ticket management to integrated ITSM, DevOps connected service management, and AI-assisted service operations. The right JSM plan should be evaluated against service complexity, scale, AI requirements, asset management, automation, governance, and operational needs. Introduction
Most organizations do not have a ticketing problem. They have a service flow problem.
An employee sends an IT request through email. A support engineer copies the details into a ticket. An incident is discussed in chat. A developer tracks the underlying defect somewhere else. A production change requires a separate approval. The knowledge needed to resolve the issue sits in an old document.
Every individual activity may work. The problem appears between them.
Jira Service Management is designed to bring these activities into a connected service workflow. Instead of treating requests, incidents, changes, knowledge, and engineering work as separate activities, JSM gives teams a common system for managing service delivery.
That distinction matters in enterprise environments. A development team can release software quickly and still create recurring incidents. Strong software delivery management looks beyond release speed to the stability of what reaches production, and JSM becomes more valuable when it helps connect these pieces.
A service desk can close thousands of tickets and still deliver a poor service experience. A development team can release software quickly and still create recurring incidents. An IT operations team can respond quickly to outages and still spend too much time solving the same underlying problem.
JSM becomes more valuable when it helps connect these pieces.
The 2026 conversation adds another dimension. AI is increasingly embedded in service management, from customer self-service and request triage to incident summaries and operational assistance. Atlassian currently provides Rovo capabilities across paid JSM plans, with more advanced service and incident capabilities available at higher tiers.
The real opportunity is therefore not to implement more Jira features.
It is to design a service operating model in which people, processes, knowledge, automation, development, and operations work together.
What Is Jira Service Management? Jira Service Management is Atlassian’s platform for managing service delivery across IT and business teams. Atlassian’s Jira Service Management product page lists the full current capability set, which is useful to check alongside the features covered in this guide.
It provides capabilities for service requests, customer portals, incidents, problems, changes, SLAs, automation, knowledge, assets, and operational workflows.
A simple service request might follow this path:
Request submitted → categorized → assigned → worked → resolved → customer notified → knowledge captured.
An incident may follow a different path:
Alert → incident created → responders notified → investigation → resolution → post incident review → corrective action.
The platform supports both workflows within a broader service management environment.
The important difference from basic ticketing is the connection between work.
A request can lead to an incident. An incident can expose a defect. A defect can become development work. A deployment can introduce a change. That change can affect a service. The service can then generate operational feedback.
JSM can provide the connective layer across that chain.
How JSM Fits Into the Atlassian Ecosystem Jira Service Management sits within the Atlassian ecosystem alongside Jira Software, Confluence, Bitbucket, and other Atlassian products.
This creates an important advantage for organizations already using Jira.
A customer issue can be managed in JSM while the underlying engineering work is tracked in Jira Software. Knowledge can be maintained in Confluence. Development activity can connect to deployment information. Operational data can feed incident workflows.
The resulting flow can look like this:
Customer request → JSM → Engineering work → Development → Deployment → Production → JSM resolution
That connection reduces the gap between service management and software delivery.
It also gives leaders a broader view of how technology work affects the services customers and employees actually depend on.
Jira Service Desk vs Jira Service Management Jira Service Desk was the earlier name associated with Atlassian’s service management product.
The product evolved beyond traditional helpdesk functionality and was renamed Jira Service Management as its capabilities expanded into ITSM, incident management, change management, asset management, DevOps integration, and broader service workflows.
So when people search for Jira Service Desk today, they are generally looking for functionality that has evolved into Jira Service Management.
The practical difference is not simply a product name.
It reflects a broader shift from managing support tickets to managing services.
Jira Service Management vs Jira Software: The Actual Difference Jira Software and Jira Service Management use the Jira platform, but they are designed around different types of work.
Jira Software is primarily used by development and product teams to manage software delivery. Its core work includes epics, stories, tasks, bugs, backlogs, sprints, releases, and development activities.
Jira Software is primarily used by development and product teams to manage software delivery. If your team is starting from scratch, this guide to how to create a Scrum project in Jira shows how epics, stories, sprints, and backlogs are set up, which makes the contrast with JSM service projects much easier to see.
Jira Service Management is centered on service delivery. Its work includes requests, incidents, changes, problems, SLAs, service operations, and customer or employee interactions.
The difference becomes clearer when looking at the lifecycle of a production issue.
Area Jira Software Jira Service Management Primary purpose Software development and delivery Service delivery and service operations Main users Developers, product teams, Agile teams Service, IT operations, support, business teams Core work Stories, tasks, bugs, epics Requests, incidents, changes, problems Customer portal Not the primary model Core capability SLA management Not the primary focus Core capability Incident management Supports engineering response Core service management capability Change management Development changes Service and operational changes Asset management Not the primary focus Supported through JSM Assets Knowledge Often through Confluence Integrated into service workflows AI use cases Development and work management Service, support, knowledge, and incident workflows
The important point is that organizations do not necessarily choose one or the other. They can use both.
For example, a customer reports a production issue through JSM. The service team investigates the incident. The technical cause is identified as a software defect. The defect is connected to Jira Software. Developers create the fix, the change moves through the delivery pipeline, and the service team tracks the production resolution.
That is where the combination becomes more powerful than either system operating independently.
Jira Service Management Features JSM has a broad feature set, but feature count should not be the measure of a successful implementation.
The better question is whether each capability removes friction from the service journey.
A well-designed JSM environment makes it easier to ask for help, route work, resolve issues, communicate status, manage risk, and learn from recurring problems.
Request Management and Customer Portals Request management gives employees and customers a structured way to ask for help.
Instead of sending an email to a generic support address, users can choose an appropriate request type, provide relevant information, and track progress.
The portal should use language that makes sense to the customer.
An employee should see something such as Request a laptop rather than an internal workflow name such as Hardware provisioning and endpoint allocation.
Good intake design matters because poor information at the beginning of a request creates extra work throughout the rest of the process.
Incident Management Incident management focuses on restoring service when something goes wrong. A typical incident process includes detection, triage, assignment, escalation, investigation, communication, resolution, and post incident review.
JSM can connect incident information with services, infrastructure, development activity, alerts, and related work.
Its current Premium capabilities include advanced incident management and AIOps functions such as alert grouping, automated incident creation, incident investigation context, and AI-generated post-incident review content.
The goal is not simply to close incidents faster. It is to reduce the impact of incidents and learn enough from them to prevent repeat failures.
Change Management Change management provides a controlled path for modifying services and production environments.
A typical change workflow can include:
Change request → risk assessment → approval → implementation → validation → closure.
JSM supports change workflows that can be connected with CI/CD activity. Atlassian currently provides deployment tracking and deployment gating capabilities in higher JSM tiers.
This creates an important bridge between governance and DevOps.
Low-risk, well understood changes can move through streamlined workflows, while higher-risk changes can receive additional controls. The objective is not to add approval steps everywhere. It is to apply the right level of control to the right level of risk.
Problem Management Incident management restores service. Problem management, one of the I TIL 4 practices , investigates why the incident happened and what should change to prevent recurrence.
Consider an application that experiences the same failure every few weeks. Incident management can restore the service each time. Problem management asks why the failure keeps returning.
JSM can connect recurring incidents with problems, corrective actions, changes, knowledge, and engineering work. This turns operational data into an input for continuous improvement.
Asset and Configuration Management Asset and configuration management gives teams visibility into the technology and services supporting the organization. This can include hardware, software, applications, infrastructure components, services, and relationships between them.
The value becomes particularly clear during incidents.
If a critical application fails, the team needs to understand which services, systems, infrastructure components, and dependencies may be affected.
Atlassian currently includes asset and configuration management in JSM Standard and more advanced asset capabilities in Premium and Enterprise.
AI-Powered Features in Jira Service Management AI is changing how service teams interact with JSM.
Current Atlassian capabilities include virtual service agents, AI-supported request handling, natural language automation, work item summaries, customer sentiment, knowledge assistance, request type suggestions, and natural language work item search.
The more interesting question, however, is not how many AI features JSM has. It is where AI can remove the most repetitive work from the service flow. That leads to four practical use cases.
Where AI Actually Changes Service Management AI for Request Deflection Many service requests are repetitive. Employees ask how to reset a password, request access, find a policy, check an onboarding process, or understand a standard procedure. A virtual service agent can use connected knowledge to answer routine questions and guide users through controlled service flows.
This can reduce unnecessary workload for human agents. The quality of the outcome depends heavily on the underlying knowledge base. AI cannot reliably compensate for outdated, contradictory, or poorly structured knowledge.
AI for Triage and Routing Incoming requests often require classification before the right team can act. AI can help identify request types, summarize context, suggest fields, and support routing.
This is especially useful when service teams receive large volumes of requests with inconsistent descriptions. The benefit is not simply faster categorization.
Better triage gets work to the right person earlier and reduces avoidable back and forth.
AI for Agent Assistance Service agents spend considerable time reading previous comments, searching knowledge, understanding customer context, and preparing updates.
AI can summarize work items and help retrieve relevant information using natural language. Atlassian currently supports AI-assisted summaries, knowledge content generation, work item search, and customer sentiment features within JSM.
This allows the agent to spend more time solving the actual service problem.
AI for Incident Intelligence Incident response is another area where AI can reduce cognitive load.
JSM Premium currently includes capabilities such as alert grouping, AI-supported incident creation, incident suggestions, and AI-generated post incident review content.
The practical value comes from bringing scattered operational information together during a high-pressure event.
AI should help responders understand what is happening faster. It should not replace human accountability for major production decisions.
What AI Cannot Fix AI is not a substitute for service design.
If request types are confusing, knowledge is outdated, ownership is unclear, and workflows contain unnecessary approvals, adding AI may simply make a bad process move faster.
The better sequence is:
Simplify the service → structure the data → improve knowledge → automate repetitive work → introduce AI where it adds measurable value.
That sequence matters more than simply activating an AI feature.
Who Uses Jira Service Management and What Do They Use It For? JSM is often associated with IT service desks, but its workflow model can support many business functions.
Any team that receives recurring requests, manages approvals, has service commitments, or needs traceability can potentially use it.
IT Operations and Helpdesk Teams IT teams commonly use JSM for access requests, hardware requests, software support, incidents, changes, problems, and service inquiries.
The major benefit is consistency.
Instead of relying on individual support engineers to remember how each request should be handled, the service process becomes visible and repeatable.
DevOps and Platform Engineering Teams DevOps and platform teams can use JSM to connect operational events with engineering activity. An incident can connect to a defect. A deployment can connect to a change. An alert can initiate an incident workflow.
This provides a stronger relationship between what happens in production and what engineering teams change in response.
HR and People Operations HR teams can use JSM for onboarding, employee requests, benefits queries, documentation, policy questions, and offboarding.
The same principles apply as in IT. Standardize intake, route work correctly, establish service expectations, automate repetitive activities, and measure the service experience.
Legal and Compliance Teams Legal and compliance teams can use structured service workflows for contract reviews, compliance requests, policy queries, approvals, and documentation.
The benefit is particularly relevant where requests are currently managed through email and the organization lacks visibility into workload and turnaround time.
Facilities Management Facilities teams can manage maintenance requests, access issues, workplace incidents, equipment requests, and vendor coordination.
Employees receive a consistent way to request help while facilities teams gain visibility into workload, ownership, priority, and resolution.
How Jira Service Management Connects to Agile and DevOps The strongest JSM implementations do not isolate service management from software delivery. They connect the two. For service teams that are newer to iterative delivery, an Agile and Scrum masterclass is a practical way to build the shared vocabulary needed to work alongside engineering.
Understanding that connection is essential for organizations trying to improve both delivery speed and service reliability.
Linking Incidents to Jira Software Suppose customers report that a banking application is failing during a particular transaction. The support team records the incident in JSM.
The engineering team identifies the underlying software defect and creates development work in Jira Software. Good defect management practice keeps that handoff clean, so the service team can see when the fix has been built, tested, and released.
The relationship can then be traced:
Incident → Defect → Development → Deployment → Validation → Resolution.
This reduces the need for manual coordination and gives both teams shared context.
Using JSM Data for DevOps Performance Measurement Software delivery metrics tell only part of the story. A team may improve its DORA metrics , such as deployment frequency, while incident volume also rises. JSM can contribute operational data such as incident frequency, resolution time, change outcomes, and SLA performance to give a broader view.
Combined with software delivery data, this provides a broader view of delivery performance.
The question becomes more useful: Are we delivering changes faster while maintaining reliable services? Teams that want to turn that question into measurable goals can set DevOps OKRs that combine delivery speed with service reliability and incident outcomes.
Change Management and CI/CD Workflows Traditional change management often creates a difficult tradeoff.
Too little control increases risk. Too much manual approval slows delivery. JSM can help create a more proportionate model by connecting change workflows with CI/CD activity.
Standard, low-risk changes can follow streamlined paths. Higher risk changes can trigger additional controls.
Atlassian currently supports deployment tracking and deployment gating with connected CI/CD tools in higher JSM tiers.
Using Service Data in Agile Retrospectives Agile retrospectives usually examine how the team worked during a delivery cycle. Bringing service data into these Agile ceremonies adds another perspective: teams can examine incidents, support requests, recurring defects, production changes, SLA breaches, and customer feedback.
If a particular release repeatedly creates support requests, that pattern becomes valuable retrospective evidence.
Production data can therefore become part of the Agile learning loop.
When Should You Use Jira Service Management? JSM becomes increasingly relevant when service work is becoming difficult to manage through email, spreadsheets, chat, or disconnected systems.
Typical signals include:
Increasing service request volumes Poor visibility into ownership Frequent SLA breaches Repeated production incidents Manual change approvals Limited incident coordination Service knowledge spread across documents Development and support teams working in isolation No clear relationship between changes and incidents Leadership asking for measurable service performance JSM is also useful when several departments need structured internal service workflows.
The decision should not begin with a product feature checklist.
Start by examining the service problem. If the problem is simply a small team handling a handful of requests, a full service management implementation may add unnecessary complexity.
If the organization has growing service volume, operational risk, multiple teams, formal SLAs, recurring incidents, and a need for traceability, JSM becomes much more relevant.
How to Set Up Jira Service Management A successful JSM implementation starts before the first project is created.
Define the service, users, request types, ownership, SLAs, escalation rules, approval requirements, knowledge sources, and reporting needs first. Admins and agents who are new to the platform will also configure it with more confidence after a Jira training masterclass that covers workflows, projects, and reporting.
Then configure the platform around that model.
Step 1: Create a Service Project and Choose a Template Start by identifying the service you want to manage. JSM provides templates with preconfigured request types, workflows, and automation to help teams get started. Use a template as a foundation rather than treating it as the final process. Remove anything your team does not need. Step 2: Configure the Customer Portal and Request Types Design the portal around the language of the customer. Keep request types clear and purposeful. A user should not need to understand internal team structures, technical terminology, or organizational ownership to ask for help. Good request design captures the information needed for routing without turning the form into an interrogation. Step 3: Set SLA Rules SLAs establish expectations for service response and resolution. Common measures include: Time to first response Time to resolution Escalation time Business hour coverage Set targets that reflect actual service commitments. An unrealistic SLA creates repeated breaches without improving the service experience. Step 4: Connect Notification Channels JSM can support service requests through portals, email, and other connected channels. The objective is not to force every user into the same communication method. The objective is to make sure different channels eventually enter a consistent service workflow. Step 5: Configure AI-Powered Service Features Introduce AI around specific service problems. Good starting points include request triage, knowledge assistance, work item summaries, natural language automation, customer sentiment, and virtual service agent capabilities. Atlassian currently makes Rovo available on Standard, Premium, and Enterprise Cloud plans, with plan specific usage allowances. Start with a repetitive workflow where the benefit can be measured. Teams that want hands-on practice with Atlassian’s AI capabilities before rolling them out can build that skill through an AI for Jira and Confluence workshop. Step 6: Test an Incident End-to-End Do not consider the implementation complete when the portal works. Run a realistic incident simulation. Create the incident, notify responders, investigate the issue, escalate it, communicate with stakeholders, resolve it, complete the post incident review, and verify reporting. This is where hidden workflow gaps usually appear. Common Jira Service Management Implementation Mistakes Creating Too Many Request Types Every organizational variation does not need its own request type. Excessive request types make the portal harder to navigate and increase administration overhead.
Designing Workflows Around the Organization Chart Customers do not care which internal team owns a process. They care about getting the service they need. Design the journey first, then determine how work should move internally.
Adding Too Many Approvals Approvals can protect the organization from risk but they can also become queues. Use risk-based approval rather than requiring every request to pass through multiple people.
Treating Knowledge as an Afterthought Self-service and AI depend on usable knowledge. If articles are outdated, contradictory, or difficult to find, both customers and agents lose time. Knowledge management should therefore be treated as an operational capability.
Automating Before Simplifying Automation is powerful. But automating a complicated process can make the complication harder to change. Simplify the workflow first and then automate the repeatable parts.
Measuring Ticket Closure Instead of Service Outcomes A high closure rate can look impressive while customers remain dissatisfied. Measure response time, resolution time, recurring incidents, SLA performance, customer feedback, change outcomes, and service reliability.
Jira Service Management Maturity Model JSM maturity is not determined by how many features an organization has enabled. It is determined by how effectively service work flows through the organization.
Level 1: Ticket Management Requests arrive through email or basic ticket queues. Visibility is limited. Processes depend heavily on individual knowledge and manual coordination. Level 2: Structured Service Management The organization introduces portals, request types, workflows, SLAs, queues, and basic automation. Service work becomes more predictable. Level 3: Integrated ITSM Incidents, problems, changes, assets, knowledge, and service relationships become connected. The organization can begin understanding patterns rather than simply processing tickets. Level 4: DevOps Connected Service Management JSM connects with development, CI/CD, deployments, operational alerts, and production data. Service teams and engineering teams can trace incidents and changes across the delivery lifecycle. Level 5: AI Assisted Service Operations AI supports knowledge, request handling, triage, automation, incident response, and operational intelligence. Human teams focus increasingly on exceptions, decisions, service improvement, and complex customer situations. This progression gives organizations a more useful definition of JSM maturity. The goal is not to reach the highest feature level but to build a service model appropriate to the organization’s complexity and risk. Jira Service Management Pricing in 2026 Jira Service Management pricing depends on the plan, number of agents, billing model, and capabilities required.
Atlassian currently lists Free, Standard, Premium, and Enterprise options for its Service Collection. The published Service Collection pricing can change, so organizations should verify the commercial terms before making a purchasing decision.
Free Plan The current Free plan is available for up to three agents at no cost.
It is suitable for small teams that want to begin using service management without an initial subscription cost.
The Free tier provides a starting point for service requests, templates, and basic service workflows.
Standard Plan Atlassian currently lists Standard at $20 per agent per month.
The plan includes capabilities such as Rovo, asset and configuration management, branded help centers, automation, audit logs, and expanded service management functionality.
Premium Plan Atlassian currently lists Premium at $51.42 per agent per month.
Premium adds advanced capabilities including virtual service agents, advanced asset and configuration management, AIOps, advanced incident and problem management, advanced change management, and deployment gating with CI/CD tools.
Enterprise Plan Enterprise is designed for organizations requiring greater scale, governance, security, analytics, and administrative control.
Atlassian currently directs customers to contact sales for Enterprise pricing. Enterprise also adds capabilities such as cross product insights, advanced administrative controls, enterprise identity management, multiple sites, and higher automation and Rovo allowances.
What Changes Between JSM Plans? The meaningful difference between plans is not simply the number of features. It is the level of operational maturity and scale the organization can support.
Capability Free Standard Premium Enterprise Core service management Yes Yes Yes Yes Customer portal Yes Yes Yes Yes Automation Basic Expanded Advanced Enterprise scale Rovo No Yes Yes Yes Assets Limited Yes Advanced Advanced Virtual service agent No Available Included Included Advanced AIOps No Limited Yes Yes Advanced change management Limited Yes Yes Yes Deployment gating No Limited Yes Yes Enterprise governance Limited Expanded Advanced Highest tier
The right plan should therefore be selected based on actual service requirements.
Buying a higher tier without changing the underlying service model does not automatically create better service management.
What Should You Evaluate Beyond JSM Pricing? License cost is only one part of the JSM investment.
Organizations should also consider the effort required to redesign workflows, migrate existing service data, integrate development and operational tools, build knowledge, configure automation, train users, establish governance, and maintain the service model.
For an enterprise implementation, evaluate:
Number of service agents Number of customers Service complexity Asset and configuration requirements Automation requirements AI use cases Integration requirements Security and governance Data residency Reporting needs Training and adoption Ongoing administration This is particularly important when comparing JSM with other ITSM platforms. For a wider view of the tooling landscape around Jira, see our comparison of Agile project management tools. Configure AI-Powered Service Features
The cheapest license is not necessarily the lowest cost implementation. Likewise, the most expensive plan does not automatically deliver the greatest business value.
The better question is whether the platform and operating model together solve the organization’s service problems.
Conclusion Jira Service Management has moved well beyond the traditional service desk.
It can connect service requests, incidents, changes, problems, assets, knowledge, development work, deployments, and operational data within a common service management environment.
That makes JSM particularly relevant for organizations trying to bring ITSM closer to Agile and DevOps.
But the platform itself is not the transformation.
A portal will not fix poor service ownership. More workflows will not fix unnecessary approvals. Automation will not fix an unclear process. AI will not compensate for weak knowledge.
The real value comes from designing a service system that is simple for users, efficient for teams, measurable for leaders, and connected to the technology delivery lifecycle.
In 2026, the next step is increasingly AI-assisted service operations.
AI can help deflect routine questions, improve triage, summarize work, support knowledge discovery, automate repetitive actions, and accelerate incident response. But the organizations that benefit most will be those that first understand their service flow.
The question should not be how many JSM features can we activate?
It should be where does service work get stuck, what creates unnecessary effort, and how can JSM help create a better flow from request to resolution? That is the difference between implementing Jira Service Management and actually improving service management.
If your teams struggle with fragmented service requests, slow incident resolution, or disconnected Jira workflows, Jira Service Management can help create a more connected service delivery model. NextAgile consulting can help you assess your current setup and co-create a practical Jira Service Management and Business Agility roadmap. Reach out to us at consult@nextagile.ai and we would be happy to explore more.
Frequently Asked Questions 1. What is the difference between Jira Service Management and Jira Software? Jira Software is primarily designed for software development and product delivery, while Jira Service Management focuses on service delivery, incidents, requests, changes, problems, SLAs, and operational workflows.
The two platforms can work together. A JSM incident can lead to a Jira Software defect, which can then move through development and deployment before the service team closes the customer issue.
2. Is Jira Service Management the same as Jira Service Desk? Jira Service Desk was the earlier name associated with Atlassian’s service management product.
The product evolved into Jira Service Management as its capabilities expanded beyond traditional helpdesk functionality into ITSM, incident management, change management, assets, DevOps integration, and broader service workflows.
3. Who is Jira Service Management best suited for? JSM is commonly used by IT service desks, IT operations, DevOps teams, platform engineering teams, and organizations that need structured service management.
It can also support HR, legal, facilities, compliance, customer service, and other business functions that manage recurring service requests.
4. Can non-IT teams use Jira Service Management effectively? Yes. Non-IT teams can use JSM for employee onboarding, HR requests, legal reviews, facilities management, compliance workflows, procurement requests, and other internal services.
The key is to design the workflow around the service being delivered rather than simply copying an IT helpdesk model.
5. How does Jira Service Management connect to DevOps pipelines? JSM can connect service management with development and deployment activity.
Incidents can be linked to engineering work. Changes can be associated with deployments. CI/CD activity can provide context for change management and incident investigation.
Higher JSM tiers currently provide deployment tracking and deployment gating capabilities with connected CI/CD tools.
6. What AI features does Jira Service Management have in 2026? Current JSM AI capabilities include virtual service agents, AI-assisted request handling, natural language automation, work item summaries, knowledge assistance, request type suggestions, customer sentiment, natural language search, and incident related AI capabilities. The exact functionality available depends on the JSM plan and configuration.
Skip to content 
