Configure Services: settings, permissions, and references

Who this is for: Anyone with edit permission on a service schema in Assets who's setting up or maintaining the services for their team. If you're new to services, start with What are services?.

This article describes the new Services experience in Jira Service Management, which uses Assets schemas as the underlying data model.

Free plan: Services aren't available on the Free plan after 31 July 2026. Upgrading to any of our paid plans (Standard, Premium or Enterprise) will unlock access to Services.

Once your services are created, you can configure who can manage them, define service object types and tiers, and map how services reference each other — so when something breaks, your team knows exactly what's affected.

This article covers:

  • Permissions — how service permissions work and where to set them

  • Service object types and attributes — the mandatory fields every service needs

  • References — how services reference each other, and how to view those connections in the service graph

How permissions work

Services in Jira Service Management are powered by schemas in Atlassian Assets. Because of this, service permissions are governed by the permissions set on those Assets schemas — not by JSM project roles.

Permissions can be set at three levels:

  • Global — applies across all schemas

  • Per schema — applies to all service object types within Software Registry and Business Portfolio

  • Per service object type — applies to a specific type of service within a schema

To configure permissions, go to the Assets schema settings for your service schemas. You'll need permission to manage the schema itself to change its permission settings.

Actions that require edit permission on the relevant schema or service object type include:

  • Editing a service

  • Managing references

  • Changing the owner team

  • Deleting a service

  • Changing values of attributes

  • Adding custom attributes

Service attributes

A service is an object in an Assets schema, and like any Assets object it has a set of attributes you fill in. Some attributes are included out of the box, and three are mandatory for every service:

  • Name

  • Tier — the criticality level of the service (for example, Tier 1 for the most critical)

  • Service object type — see below

You can create additional custom attributes to capture any other information your team needs.

Out-of-the-box service object types

Services are organised into two pre-provisioned Assets schemas, each with its own set of object types:

Schema

Object types

Software Registry

Applications, Capabilities, Software Services, Deployed Services

Business Portfolio

Business Services

You can also create custom object types in either schema. The two schemas are pre-configured so you can start adding services right away — no setup is required.

Manage services from Assets

Because services are Assets objects, you can also create and edit them directly from the Assets schema view — not only from Operations → Services in Jira Service Management. Either entry point updates the same record.

Change a service's owner team

  1. From the JSM navigation, go to Operations and select Services.

  2. Open the service.

  3. In the service details, find the Owner Team field.

  4. Select the field and search for the new team.

  5. Save your changes.

Changing an owner team affects how your team identifies and responds to incidents involving that service. When an owner team is added to a service, the on-call schedule of that team (defined in Jira Service Management → Operations) will appear in the Service detail view. See How services work with incidents.

Add references between services

References describe how services relate to each other — for example, your customer portal references your authentication service, which references your database. Mapping these connections means that when an incident affects one service, responders can see what's upstream and downstream from the incident view.

Two reference attributes are included out of the box, matching the two pre-provisioned schemas:

  • Software Registry references — link to objects in the Software Registry schema (Applications, Capabilities, Software Services, Deployed Services, or any custom object types you've added to that schema)

  • Business Portfolio references — link to objects in the Business Portfolio schema (Business Services, or any custom object types you've added)

Each attribute uses Depends on as the default reference type. You can create additional custom reference types to suit your team's needs. All reference types are functionally equivalent — there's no special behaviour (such as auto-reverse-linking or deletion blocking) based on the type you choose.

Add a reference

  1. Go to Operations → Services and open the service you want to add a reference to.

  2. Find the Software Registry references or Business Portfolio references attribute.

  3. You can add multiple service objects per attribute (up to 100)

  4. Select the attribute and search for the service to reference.

  5. Save your changes.

Remove a reference

  1. Open the service whose reference you want to remove.

  2. Find the relevant reference attribute.

  3. Select the reference, then remove it.

  4. Save your changes.

Each service supports up to 100 references in total.

View the service graph

The service graph shows a network diagram of a service and its references — so you can trace dependencies and understand impact during an incident.

The graph is available per service. You can open it two ways:

  • From Jira Service Management:

    • Go to Operations → Services

    • Select a service - this opens up a panel from the right with details about the service

    • Look for the graph view option in the panel

  • From Assets: open the service object in your Assets schema and select the graph view option there.

Filter the service graph

You can filter the graph using these options:

Filter

What it does

Reference type

Show only references of a specific type. For example, filter to Depends on to see only services this service depends on.

Reference depth

Limit how far the graph traces references from the current service. For example, set depth to 2 to see direct dependencies plus their dependencies.

Inbound reference grouping

Group services that reference the current service. Useful when many services depend on yours — grouping reduces visual noise so you can see the structure at a glance.

Troubleshooting

Issue

What to do

I can't see Services under Operations.

The new Services experience may not have been rolled out to your site yet, or you may not have the required Assets schema permissions. Ask your admin to check.

I can see a service but can't edit it.

Edit access is governed by Assets schema permissions. Check your permission level in Assets for the relevant schema or service object type — or ask whoever manages the schema to grant edit permission.

Still need help?

The Atlassian Community is here for you.