nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Change Management

Coby Fuller

** As a disclaimer, I'm aware that Jira Service Management does include a change management template, but we do not have Jira Service Management.

I'm curious if anyone out there in Jira Admin world has developed a solution for change management in Jira software? I have a user base of about 250 and often receive requests for customization or configuration changes to our Jira instance. These requests could be for global changes or project level changes. Regardless, it is a very manual process for me to track down anyone that could potentially be affected by these changes and make sure they understand and approve.

I have a 'Jira Admin' project that contains a 'Jira Request' issue type. Currently, the workflow is very simple for the Jira Requests (To Do, In Progress, Pending, Done), but I was considering adding approval steps to this workflow. The idea is to have new requests go through some type of approval before it even falls on my board for actions to be taken. The problem that I'm having a difficult time solving is that we need approvals from at least one development lead, one solution architect, and one business analyst supervisor. This would be easy enough to solution through the workflow by adding an 'Approved' status if we just needed a single approval, but we are wanting to make sure all teams are aware of possible changes.

Comments

Karri Adkins_ma1xcf

I created a jira project that I ask everyone in my Org for Engineering to enter a ticket, then we in the PMO review it before we implement. Our Operations teams do the same for their part of the Org. We have created our own workflows and approval process for these. It seems the best options, for us, thus far, as you know, if you don't do something in this area, you will lost track of it all quickly. We used to keep up with a confluence page where we tracked only major changes to workflows, that worked well, but it still didn't give us the volume of requests that come. This does.

Wendy McCurdy

I think you can tackle in a couple of ways (I'm not expert, so this is just my brain storming).

1. Use multiple steps in a workflow, Open -> Dev Lead Approve -> Solution Architect Approve -> Business Analyst Approve -> Ready -> In Progress -> Done. It would mean that one would need to approve before going to the next approver.

2. Use automation where when a request is submitted and email is sent out to each team member or group that needs to approve. Then add additional automation to look for certain text and when it meets the criteria moves the workflow status. I have done some automation that looks for certain text such as "//Dev Approve//", and when there is a special text for each team then it will move to ready.

As I said, just a couple of ideas.

Karri Adkins_ma1xcf

Because the Audit trail in Jira is pretty slim.

Karri Adkins_ma1xcf

We also added in workflow steps where the button displays for the type of approver, and auto assigned to that approver. This way once it is approved, jira shows who approved.

If for an alternate, we re-assign it, and then that person clicks to approve, and the audit trail shows who clicks on that action so we have an audit trail for that approver.

Paul O_qqk8km

Yes, JSM should be your first choice but it’s perfectly possible to build out something functionally similar in Jira - especially if you have access to Automation and/or add ons like JMWE.

For approvals, you can use a hidden field as a counter and increment the value each time an approval is received. Once the value equals the correct number you can use automation to transition the ticket to an approved status (or simply add a condition to the transition so that it requires noApprovals = 3, for example).

To increment the counter you can either check approval comments and use groups to ensure that comments are coming from the right stakeholders or use a circular transition to create an approval action that is only visible to appropriate individuals and increments the counter on each approval

Jennifer Choban - HeroCoders

These might be helpful. They assume JSM, but you could build it in software:

https://docs.thinktilt.com/proforma/ITSM-Use-Case:-Change-Management-Normal-Change.1646821987.html

https://docs.thinktilt.com/proforma/ITSM-Use-Case:-Change-Management-Standard-Change.1646952483.html

Coby Fuller

@Paul O Thank you for taking the time to respond. This is useful information and helped me get closer to a solution.

Coby Fuller

@Wendy McCurdy Thank you for taking the time to respond. I'm attempting a bit of a combination of your suggestion and @Paul O

Coby Fuller

@Jennifer Choban - HeroCoders Thank you for taking the time to respond and providing the link.

Coby Fuller

@Karri Adkins Thank you for taking the time to respond and providing your teams solution.

Production Management

I had same problem as you and I created a new issue type Approval. It has three statuses - Open, Approved, Declined. I also added a manual trigger rule for Automation. It creates Approval issue and copies Description and Summary from original issue adding something like "Approval required". After issue creation it links it to original issue as Blocks.

Now every time anyone needs approval he/she selects the rule on the issue view page and triggers it. Immediately one can see a linked ticket and its status.

If you need three approvals from several persons - easy, just copy the rule two times and make different assigners.

That's all.

Josh Costella

Hi Coby,

It seems like all of the responses have gone the functionality route. Creating the functionality for approvals in Jira is relatively straightforward so I'm going to avoid duplicating efforts here. What I would like to focus on is on your process as that seems like the actual problem needing to be solved. I'm going to pose several questions because I want to better understand your process and see what I can do to help! I promise this is not me saying you are doing anything wrong, but I can't help but try to help when I see a process that can be improved.

I have a user base of about 250 and often receive requests for customization or configuration changes to our Jira instance. These requests could be for global changes or project level changes. Regardless, it is a very manual process for me to track down anyone that could potentially be affected by these changes and make sure they understand and approve.

The first question I would ask is do you have any process restrictions on who can request changes to Jira? It doesn't sound like there are any if you have to then follow a manual process to track down stakeholders to inform and gain approval. I would consider adding one along the lines of only users who are managers and above can request changes to Jira functionality. That would reduce the need to contact people on behalf of requesters since you are funneling the changes via the stakeholders who need to "approve." If you can't change that, I would at least suggest requiring the requester of the changes to gain approval from all affected stakeholders before you begin work on the request. At least that would reduce overhead for you.

The problem that I'm having a difficult time solving is that we need approvals from at least one development lead, one solution architect, and one business analyst supervisor. This would be easy enough to solution through the workflow by adding an 'Approved' status if we just needed a single approval, but we are wanting to make sure all teams are aware of possible changes.

Why does your process require so many approvals? What is your process around communicating changes? Do you think adding an approval process to the workflow will solve the problem of making all the teams aware of possible changes? Also, do all those teams need notified or does it depend on the change? How would you determine which change needed approvals? Do all of them or just ones that affect more than one team? If the changes affect more than one team, how would you account for that in the workflow since you have single approvals from each role? Are the roles providing approvals made up of people who are also atlassian admins? Do they have the necessary knowledge and experience to understand what they are approving? Are you empowered in your position as an Admin to say "no" to a requested change?

I ask all of these questions because, in my experience, the more the admin role can "own" what goes into the tools, the better. Gaining approvals from multiple sources is a last resort. I'm not saying you should make changes without telling everyone but you should feel comfortable enough and be empowered to question and analyze a change, its impact, and then make the call if a change should proceed. And then, and only then, should you seek approvals from stakeholders.

Approvals are going to be emails. Emails are unreliable. People reading and responding to emails are unreliable. Needing so many approvals is going to create a bottleneck and then you will have to deal with requestors being annoyed at how long their requests are taking to be completed. It will look bad on you even though it won't be your fault. If you need to gain approvals, I would consider adding approval notifications in multiple locations depending on what other communication tools you have. Ultimately, keep the process simple. Communicate only when you absolutely need to. Don't bother people unless you have to.

Alexander Stern _ Shern Consulting OÜ

This is a pretty common setup when teams don’t have Jira Service Management.

What I’ve seen work in practice is combining a request project like yours with explicit approval steps in the workflow, plus automation to notify the different roles (dev lead, architect, business) and require their input before moving forward.

The tricky part is not defining the workflow itself, but making sure all approvals are actually visible and traceable over time — especially when changes happen frequently or outside of the formal request process.

In larger instances this often becomes more of a governance and tracking challenge than just a workflow design problem.

Welcome!

It looks like you're new here. Sign in or register to get started.