The system of record for what anyone is allowed to change.
Jira Service Management holds incident, request, change, problem, and knowledge work as connected practices, with the asset model and the approval record alongside them. Our work is catalog rationalization, change control, assets and CMDB, identity, and consolidation onto one platform.
JSM is where change control, approvals, and the asset model actually live. We consolidate what is scattered across other tools, define what approved means, and build it so a small team can administer it.
What it is
Jira Service Management holds incident, request, change, problem, and knowledge work as connected practices, with the asset model and the approval record alongside them.
It is for organizations running service management somewhere else, or in several places at once, where a ticket, a problem record, and the engineering work item sit in three systems that do not know about each other.
What it does
Change with an approval record
A change carries its risk model, its approvers, and the request that generated it, rather than an email trail somebody has to reconstruct.
Assets that describe the estate
Devices, people, vendors, and locations with relationships modeled, synchronized from the systems that already hold them.
One configuration, many teams
Shared workflow, field, and permission schemes mean a change made once applies everywhere it should.
Intake people actually use
A structured portal, email that routes on content, and knowledge surfaced while a request is being typed.
Where it fits
L3, governance and change. This is where the platform stops being a place work is tracked and starts being the record of what was decided. Change control, the approval model, and the asset relationships live here, which is why the layer above it, automation, has nothing to obey until this one is built.
What we do with it
Implementation and consolidation
Catalog rationalization, service projects, workflows, SLAs, assets, automation, and cutover, delivered as one engagement rather than several.
Change control design
Deciding what approved means, who decides, and what evidence is attached, before anything is automated against it.
Identity and the permission model
Guard configuration, provisioning, and a group model covering employees and external vendors.
Moving off the incumbent
Migration of the catalog, the assets, and the knowledge, with decommission support for the tools coming out.
Running it afterwards
Tiered support, administration, and the improvement backlog, so the configuration does not drift.
Where it earns its place
A carrier on a legacy on-premise service desk
Where the incumbent cannot reach endpoint tooling without custom scripts and agents cannot work off the network, the platform question answers itself.
An estate with several instances of the same process
Divergent copies of one workflow are the actual cost. Consolidation is a rationalization exercise before it is a migration.
An organization with a change advisory board that meets anyway
A defined approval path does not remove the board. It removes the part of the meeting spent establishing what was requested.
Proof
Of security leaders say they govern access to their core platforms effectively. Change control is where that is either recorded or lost.
2026 CISO AI Risk Report, 235 large-enterprise leaders.
Questions we get
Is this ITIL?
Can our own team administer it?
Do we have to move assets in at the same time?
What about the tool we are leaving?
Licensing
Service management is licensed by agent rather than by end user, so the count worth checking before a renewal is who genuinely needs to work a queue. That reconciliation sits with the rest of the estate in licensing and renewals.