Forms Use Case: Managing a Normal Change with Jira Service Management

[#1]

This is a Jira Service Management Forms Use Case. We’re publishing a series of these use cases here on Community to share how teams are using forms to deliver high velocity service. Click here to see all published forms use cases. Because this is the first post, it may be a short list for now ;) 

Welcome to the forms use case series!

Hi there! We started rolling out the new no-code form building experience to Jira Service Management customers in December 2021 and since then we’ve seen a lot of people begin to use the new features.

Over the next several weeks, we’ll share a handful of in-depth use cases and form ideas to help users who may be new to the no-code form builder get started using these new features.

This first use is about running a Normal Change process. Be sure to check back next week to see how other customers have managed a similar (but different) process, the Standard Change use case.

Scenario

The IT team has determined that they need to add a new server.

Who's involved?

• IT team member(s)

• Change Manager

• Change Approval Board (CAB)

• Emergency Change Approval Board (eCAB)

Typical Issue Life Cycle

1. An internal IT team member completes a Change Request form on a Jira Service Management help desk that is only exposed to the IT team. 

2. Depending on the change type (standard changes can be routed straight to AWAITING IMPLEMENTATION status), the Change Manager adds a Risk Assessment form to the issue. Determining that the risk is acceptable and that the change is likely to be successful. The Change Manager transitions the issue to PLANNING and adds the appropriate Deployment Plan form to the issue.

3. The change owner fills out the Deployment Plan and changes the issue status to AWAITING CAB APPROVAL.  When the issue transitions, a CAB Review form is automatically added.

4. The Change Approval Board reviews and approves the plan and transitions the issue to AWAITING IMPLEMENTATION. (For Major Changes, the issue can be transitioned to AWAITING MAJOR CHANGE APPROVAL and a second approval form can be automatically added.)

5. The Change Manager adds the Issue to the Change Management Confluence Calendar.

6. When ready, the Change Manager changes the issue status to IMPLEMENTING and adds an Add Server Checklist to the issue. Work begins and the team records their progress on the checklist.

7. Upon completion, a team member transitions the issue to POST IMPLEMENTATION REVIEW.

8. For normal, major, and emergency changes, the Change Manager will add a Post Implementation Review form to the issue. The Change Manager will complete the form and transition the issue to CLOSED. A workflow validator ensures that all of the forms on the issue have been submitted.

Setting up automation

Set up automation for forms to:

1. Add a CAB/Management Review form when the issue is changed to AWAITING CAB APPROVAL

2. Add a CAB/Management Review form when the issue is changed to AWAITING MAJOR CHANGE APPROVAL

3. A workflow validator ensures that all forms on the issue are submitted before the issue can be CLOSED.

Set up notification automations to:

1. Notify CAB members when there is an issue awaiting their approval

2. Notify eCAB members when there is an issue awaiting their approval

3. Notify Managers when there is an issue awaiting their approval

A note on automation and forms

At the time of this post, form automation has not been released. We are working on an integration of forms with Automation for Jira that will enable you to recreate this use case and other similar workflows. We’re sharing this now so you can see what’s possible when the ability to leverage automation and forms is available.

Workflow

Forms

All forms listed below are available as a Jira Service Management form template. Learn more about creating and editing forms here.

Change Request	Change Risk Assessment
CAB/Management Approval	Server Deployment Plan
New Server Checklist	Post Implementation Review

Unique Advantages

• All of the information associated with the change, from the request to the post-implementation review, is available on the issue for easy viewing, auditing and compliance assurance.

• You can create and select among various Deployment Plans and Checklists, reducing the number of request types required. You can also reduce the number of custom fields needed to run this process.

• A deployment checklist is an easy alternative to creating subtasks.

• While forms such as the Risk Assessment and Post Implementation Review are kept on the request for easy access, a spreadsheet with all submitted form responses can be downloaded for data and trend analysis.

[Fabian Lim]

Great article!

[Fabian Lim]

Hi @Peter Preston

We are a heavy user of Pro-Forma in DC, is Jira Forms pretty much the same with some enhancements?

[Peter Preston]

Hi @Fabian Lim

For now the forms feature set in Jira Service Management Cloud is similar to the ProForma Marketplace app for Data Center. We are reviewing the roadmaps for Cloud and DC/Server. I suspect that over time there will be a difference between the two, but for now they're mostly the same. Unfortunately, I can't go into details about either roadmap and future releases. 

[Shastine Mosley]

Can someone easily explain the reasoning behind using Forms, Confluence Change plan or just putting all the necessary details/fields directly into the actual change form?

I realize the forms can be linked back to the fields in JIRA change screen but what is the driving factor(s) behind each?

[Peter Preston]

Hi @Shastine Mosley 👋

If you're using Jira Service Management to capture change requests, the new form builder lets you tailor your intake forms to capture the info you need. That info is then stored on the request, where you can build workflows, add multiple forms for each step of your change management process, and generally keep your work all in one place. 

[Todd Warrington]

Do we know when forms automation is going to be released?  This use case is very informative, but apparently useless for the time being...

[Peter Preston]

Hi @Todd Warrington -- you're right! It's not much use yet... Automation will be released within the next month or two. I'm not able to share a date, but it's close. I'm as excited as anyone to get automation out there so you can use these workflows to their fullest -- I'll post a date as soon as I can.

Also, we're starting a Forms Group here on Community. We'll share feature updates, open up for feedback and suggestions, and more in that group. Keep an eye on Community for an invite post (it's scheduled for March 15th PST, but you didn't hear that from me 😉)

[Han Kong]

@Peter Preston How can I join a Forms Group here on Community?

[Peter Preston]

@Han Kong you should be able to get into the Forms Group here --> https://community.atlassian.com/t5/Forms/gh-p/forms

Let me know if you have any trouble getting in 🙂

[Fabian Lim]

@Peter Preston

In our Change Management request process we started to use the forms that you mentioned above.  However, in the validators you can select the options to validate that the form has been attached or submitted.  However, there is on way to specify which specific forms need to be attached/submitted.  Is this something that can be added to the backlog?

It would be ideal to have different forms attached in the different transitions.

Regards,

Fabian