Skip to main content

01

Set up an on-call schedule for a team

Create a custom on-call schedule

02

Communicate outages, maintenance, and other key information with stakeholders

Create a communication plan using Jira Service Management and Statuspage

03

Process a change record

Enrich a change request and champion approval

04

Manage change risk

Use the change calendar and automation to identify conflicts

05

Establish SLA goals and a working hours calendar

Constrain SLA goals based on your working calendar

06

Automate the lifecycle of a request

Use automation to handle recurring tasks

07

Establish a schema that can be used throughout Jira Service Management

Create a schema to enrich issues across Jira Service Management

08

Embed an Assets field in a customer-facing request form

Expedite resolutions by linking Assets data

09

Allow for approvals in a workflow

Demonstrate an example of how approvals work

10

Establish a knowledge base with organized articles

Deflect requests with knowledge base articles

11

Create a complex portal form

Understand how and when to use ProForma

12

Create contextual queues for agents

Contextualize and configure queues based on the job to be done

13

Add, remove, or modify a request type in the portal

Learn how to create and organize request types to serve customers

14

Cross-link tickets and/or articles to add context to an issue

Enrich a Jira issue with contextual links

15

Collaborate with non-agents in Jira Service Management projects

Learn how to work with non-agents using Jira Service Management

16

Report on issue data over time

Measure time-based and success-based metrics

Process a change record

Outcome	Your team will understand how to enrich a change request and ensure that it’s approved.
Processes	Submit a request Include required documentation Review change calendar Review approvals Cross-link the change request as appropriate Champion the change through the approval process Communicate
Practice area(s)	Change enablement and incident management
Product(s) in scope	Jira Service Management, end-users, and customers
Role(s)	Team members

Change Types

Step	Process	Notes/References
1	INITIATE Submit a new change request Internal service team member submits a change request Only minimal data is needed in the request: Service/application affected Urgency Impact Type of change (for example, standard, normal, or emergency) Risk Proposed start date Overview of implementation steps Description of the change Change requests can be initiated through linked incidents or problems (or may have no relation to existing items)	What is the change management workflow in service projects? The evolution of IT change management
2	PLAN After the submission, the team and change manager review the details and then add/amend the change request. 1. Reviewing the change request may require you to add additional information to the change request to ensure a higher chance of a successful implementation. 2. Evaluate if there are any other related services/applications that may be affected or within the scope of the change. Note: The goal of this step is to ensure that all relevant information has been captured and supporting work has been linked.	Change management How teams share change management roles and responsibilities
3	PLAN After review, the change owner/team plans to implement the change. 1. The change manager will consult the change calendar to ensure no conflicting changes are planned in the schedule. 2. Consider what the appropriate communication plan should be. Audiences of communication may include: End-users of the application/consumers of the service Stakeholders/owners of the application/service Owners of related applications/services	What is the change calendar? Show change requests on the change calendar
4	AUTHORIZE Depending on the type of change and internal guardrails, specific levels of approval may be required. - Standard changes are typically low-risk, may only need approval from the change manager (or require no approval), and are fast-tracked to implementation. - Normal changes traditionally require both change manager and CAB approval. - Emergency changes may require approval or authorization before implementation, depending on the service or application. Definitions of the types of changes, and the related level of approval needed, will vary significantly based on the internal processes in the organization. For service teams getting started with change management, we recommend starting with a light approval process to avoid turning change management into a giant bottleneck to getting work done.	Types of change management How teams share change management roles and responsibilities
5	IMPLEMENT & VALIDATE After finishing the above review and authorization steps, next, the team implements the change on the scheduled date. The team implementing the change should document the outcome as a success or failure (resulting in a regression of the change).
6	CLOSURE After implementation, the change manager closes the request. 1. After implementing (or attempting to implement) the change and updating the documentation, close the original change request. 2. Link any new and all supporting documents and artifacts to the change.

Communicate outages, maintenance, and other key information with stakeholders

Previous step:

Next step:

Manage change risk

Was this content helpful?

Connect, share, or get additional help

Atlassian Community

Related links

Bottom banner image

Purpose-fit guidance and support to ensure your team's success

Each deployment of Atlassian products is unique, so we offer a breadth of services to design, implement, and optimize solutions for scale.