Jump to content

My Articles

These are articles written by me, Jimi Wikman. These articles are written on a wide range of topics. The main focus is of course on Atlassian, but as I am also very much interested in other areas that I have worked, or are just interested in you will also find other categories here. Under Ways of Working you will find articles relates to the build process management, design, requirements, development, test, operations and support. Under Interesting I write about security, e-commerce and Invision Community. Under professional, I write about work as a consultant, work related health issues, business related news and other topics related to professional work.
Show all categories

The balance between Chaos and Red tape - the cost of failure is very high

Ways of Working,
If you spend any time in the ecosystem of work processes, methodologies and frameworks you have undoubtedly encountered people that claim that one way or another is the only way to do things and if you disagree, then you are stupid, uneducated or even evil. These are the fanatics bordering on cultists clinging to one way to rule all ways and there is little point arguing with such people, unless you like me enjoy a bit of an argument just to see what their point of view actually is.
There is of course no one way of doing things.
Just as people are different, so are teams and organizations. Claiming that Agile for example is always the right choice makes no sense as you will always have people that do not work well in Agile settings, whatever they might be. It is equally wrong to claim that we must have strict rules, or structures for how to do things, for the same reason. Some people, teams and organizations thrive in loose structures that allow them to use their creativity and make quick decisions on the fly, while others thrive, or even are required to have more structure and processes in place.
Selecting the right balance is key, but it does not just matter for productivity, it is also very important for health and motivation.

Ad-hoc behavior is harmful for your health
I recently read about a developer that despaired and lost all interest in his work because the workplace was chaotic with a start-stop culture. This is sadly not an uncommon situation and if you have never experienced a start-stop culture, that is when work is constantly started and never get finished because it is being shut down and something else takes its place. This is one of the most detrimental ways of working as it induces a lot of stress in the individuals that are exposed to it.
There are many studies that show that unclear expectations and an unstructured workplace causes stress. Not only will this have negative impacts on the ability to do deep thinking, but it also causes long term ill effects, which can eventually become serious health issues. I have seen more than my fair share of people passing out in meetings, burning out and even being hospitalized after being picked up in an ambulance.
Stress is no joke.
The tricky part about ad-hoc behavior and unstructured work is that every individual have different tolerance levels for stress. For some it will be a slight nuisance, for others cause for frustration and for some it is directly harmful. This is why it is so important to make sure you understand the cost this comes with for your people, your teams and your organization.
Ad-hoc behavior can come from many sources. One source is that the organization is a startup and both financial constraints and the behavior of the founder drive the organization towards ad-hoc. The false pursuit of freedom is another where individuals or teams believes that if they can just get away from the "oppression" of management they can make the world a better place. A third is that an organization is made up of many subdivisions, most commonly due to purchasing multiple other organizations and trying to merge those into a larger whole.
In many organizations having too much ad-hoc behavior and unstructured work will manifest as loss of financial value as people are running without the ability to do deep thinking, sick leave is high as people get sick from stress and a high turnover rate as people leave the stressful workplace.

Red-tape behavior and micromanagement
The opposite side of the coin is where everything is controlled and everything you want to do is tightly controlled in strict processes and rules. Just as ad-hoc behavior causes stress, so do red-tape behavior, but for a different reason. Where ad-hoc behavior cause stress due to unclear expectations, red-tape causes stress because it demands so many blockers that progress crawls to a halt. In many cases it feels like actually getting permission to do something require more work than actually doing something.
Besides stress building up from constantly being held back because of long processes to do anything, micromanagement is also a common symptom. That is because just as red-tape tend to be the result of low trust in the people that work in the organization, that is also why micromanagement exist. It is not uncommon that a company start out as an ad-hoc organization and then transition to a red-tape as the organization loose trust in the chaotic nature of the ad-hoc ways of working.
From my own experience and from talking to other people on the subject there seems to be a correlation between when organizations start to expand on the proxy culture. This is where management is multiplying because the workload is too much and by doing so they create an elaborate number of levels of managers that all act as proxies. The opposite happens when organizations realize that the amount of managers doing nothing but attending meetings and relaying information is an expensive way to operate. This tends to lead to a swing towards ad-hoc again and when trust is lost again we see a raise in the number of middle managers again.
In fact, most organizations continuously vary between these two states and the impact that has depends on how large those swings of the pendulum are. If your organization is stable the pendulum will make small swings and if the organization is volatile, then it will make larger swings. These swings tend to be triggered when an organization has built up enough incompetence, so that trust is eroded. If it is trust in Management, then it will tilt towards ad-hoc and if it is in the teams trust has been lost, then the swing moves towards red-tape and micromanagement.

The impact on "creativity"
While you might think that a restrictive red-tape behavior would strangle any creativity and an ad-hoc behavior would have a positive impact, that is not necessarily true. The devil is in the details and most people do not define what they actually mean with creativity and then confuse brainstorming with creatively making decisions that benefit the organization.
If the purpose of creativity is to come up with as many ideas as possible that you throw out and see what sticks, then ad-hoc is the way to go. It has very little deep thinking and most of what comes out are brain farts, but occasionally something amazing will come of it. It is just a matter of how long your company can survive by paying for the people to throwing shit on the wall until something sticks.
If the purpose of creativity is to come up with ideas that are valuable every time, then you want to go with the red-tape option. It will take forever to find that value, and you will spend an insane about of time to figure out what to do next. You will spend more time in deep thinking and filling out forms than coming up with new ideas, which will put you in the same position and the ad-hoc behavior.

This has nothing to do with your process, methodology or framework.
It does not matter if you are an Agilist swearing that Scrum, Kanban or maybe just an undefined Agile way is the ambrosia of the gods that promises eternal bliss, or if you demand that the world bow to a traditional project management methodology like Price 2 or what we refer to as Waterfall. All of them will work just fine as long as you adjust the way you work based on the people doing the work. In the same way none of them will work if you take them too far and either don't take the people into consideration, or you push things too far towards ad-hoc or red-tape.
At the end of the day it is the work you do, the collaboration and understanding you engage others with and the value you actually generate, regardless of position. Not the buzzwords, not the rituals and not the processes. These are just the guardrails that should help you stay on the path of being good colleagues and employees working together towards a common goal.

The balance is everything
In order to maximize this and get a good work environment that will keep people happy, healthy and creative is to find the balance between ad-hoc and red-tape. This will not sit well with people that are either have very active and chaotic minds, or the people that have very rigid minds that demand structure in all things. These are the people that are the most vocal in the discussions in different forums in my opinion, and they are also the ones that drive the swings of the pendulum when they join organizations
The key towards a balanced organization is to ensure you have enough steering so the organization benefit from it, but enough flexibility so that teams and individuals can be at their best. This is an extremely difficult balance and from my perspective the only way you can achieve this is by looking at the problem from both directions.

Top Down for structure
From a management perspective we need steering and structure on the large scale. A governance model should be put into place where representatives of all disciplines within the organization are represented. This governance group should define the high level processes and the high level requirements. Things like what kind of documentation do we demand, what are the legal requirements that everyone should abide to and so on is on the highest level. Here you have the larger processes for funding projects, how budgets should be defined and so on.
This is also where the discipline specific things should be defined, like for developers we should have documentation standards, legal requirements, standard tech-stack for various type of work, standard tooling and what the developers need as input and what they are expected to have as output towards other discipline groups.
Large brushes, but without going too far into the red-tape behavior. The purpose is to define high level requirements for high level processes.

Bottom Up for creative freedom
With the governance group setting the big stage, the teams focus on how to make their group of individuals work best. Withing the structure provided by the governance team how should the teams work to be as productive as possible. This is where team leaders will be very important as most people have no knowledge or competence in team dynamics or group psychology. This is a crucial skill that the team leader need to have to ensure that we don't get strong willed individuals bullying their way for the team happen.
While the governance group have defined a standard for th whole organization, it is ok for teams to deviate from this if they see that the can do that without compromising the bigger picture and that it is adding value to the team as well as the organization. The same thing goes for things like documentation and requirements where the outcome might be defined in the governance group, but the team can decide how to get there.
At this level the teams meet the requirements from the governance group with details on how they will work towards those goals within those structures.

Leadership is the key, not management
Finding a balance between ad-hoc and red-tape require constant leadership and change management. While managers have their place, their job is not to lead the organization, but to manage the work. In order to do this effectively managers also need to have a good understanding of leadership and change management as their position will grant them a larger overview than the team leaders and a more granular one than the leadership levels or the governance group.
I also think that all teams should learn about leadership and I think many would benefit greatly from things like team dynamics, group psychology and even personality types that I know many are against. Understanding how you and others work in a group and what kind of leadership is required in what state is to me the key to a bottom up approach towards a balanced organization.
Leaders lead the way, managers manage what you already have.
--
So the question is if your organization is a leader,
or are you stuck on the pendulum as it swings,
unable or unwilling to try to make it stop?
Jimi Wikman
By 💫 Jimi Wikman in Ways of working ·

Playbooks in Jira Service Management add much needed support for Agents

Jira Service Management, Playbooks,
I stumbled upon Playbooks today by accident in my Jira Service Management settings and since I had missed the announcement I was first a bit puzzled. I went into the Release notes in my Admin section and sure enough there it was. No image, no real information and the link to the official documentation is not really providing any reason to look into this any further. Now that it has landed in my Jira Service Management instance though... Oboy, this is amazing!

What are Playbooks in Jira Service Management?
Well, the short answer is that is a combination of a checklist, an instruction and automations in one nice package. It behaves like Automations in that you create steps that can be either instructions or automations. You will find Playbooks in your Jira Service Management project configuration settings below the Automations. From there you will see the existing Playbooks so you can manage them.


The Playbook itself can be setup with some conditions, which are very few at the moment. You can set up conditions based on issue type, request type and groups at the moment, and it would be great to also have other choices like custom field values and perhaps the check for Major Incident.

When you create the steps you can choose between Instructional and Automations. The Instructional option is quite straight forward where you will add information in a rich text editor that will assist the agent. There is a limit of 500 characters at the moment, which I assume is because they are just rolling things out as an MVP. In the future they probably need to change this as 500 characters is not a lot. You can of course add links to longer documentation and for now adding a link will just output the link so you can't use the internal linking feature to show pills or full embeds.

The Automation option allows you to add any automation in scope for the project. I think it will only allow you to pick the automations that have a manual trigger though. This makes sense since it will output a button for the agent to click, so other types of triggers does not make a lot of sense.


Once you have created the Playbook then all you have to do is to save it. If you have set up any conditions then those will determine when the Playbook will appear, but you can also add the Playbooks manually in the tickets. In your tickets you will see a new section for Playbooks marked with the New label.

Once you click to expand the Playbooks area you will see a list of Playbooks and when you open a Playbook you will see the steps. Each step will display the instructions and if it is not an automation, then you will see a button that says "Mark as done". For automations the button will instead say "Run". This is a great way to keep track of what you have done and a new way to add a checklist of things that you need to do for certain tickets.

Once you have completed the activities and clicked the buttons your actions will be saved in the execution log. The execution log is showing up both in the Playbook itself and in the execution log in the Playbook session of your project configurations. For now, it seems that if you press the button by accident, there is no way to revert that action!

Once the Playbook has been run you will find the result in the execution logs where you can see the result, who did what and when.


Are Playbooks in Jira Service Management useful?
Even though this is still very bare bone, and we need some additional love for it, I would say this will solve a ton of problems that people currently are struggling with. I had a conversation with a customer this week about a scenario just like this, and it is one I have had many, many times before.
This is very useful for incident management of course, but also for service requests and basically any situation where you want to ensure things are done in the correct order and to make automations a natural part of a checklist.
To me, this is one of the sneakiest and most awesome feature I have seen in a while!
Great work Atlassian!
Jimi Wikman
By 💫 Jimi Wikman in Atlassian ·

The renaming of Issues and making work as the new collective term for all items tracked in Jira

Jira, Jira Service Management,
Back in September last year Atlassian announced the shift from the old term "Issue" to something more appropriate. This caused a lot of opinions and Atlassian put out a poll to see what word their vocal users liked the most. This was followed by an announcement in November 2024 where the term Work was announced to replace Issue. It is no understatement that people lost it a bit over this and when the rollout was announced in March 2024 the comments section lit up quite a bit.

But what is the big fuss about, and why are people upset?

The history of Issues in Jira
Let us first start with the background on why we even have a word like "issue" in Jira to begin with. This starts back in 2002 when Jira was first released. It was released as a bug tracker and when you are working with bugs, it makes sense to refer to the work you are doing as "issues". As Jira evolved, perhaps most noticeable with the purchase of GreenHopper in 2009. This was an Agile plugin developed by Pyxis Technologies that had release planning, task management and burn down charts.
This changed Jira from a bug tracker to a more useful product capable of tracking work rather than just bugs.
As Jira continued to evolve with new functionality and new ways to use Jira, the terminology did not change with it. Work that was done remained named Issues and over time this has strangely become normal terminology among the users that have been using Jira for a while. For new users however, the term has always been confusing and many of us that has been working with Jira for a while have heard people questioning why this term is used to describe work.

The big Jira shift - Teams '24
In 2024 at Teams '24 in Las Vegas Atlassian announced the biggest change in the history of Atlassian. One of the two founders, Scott Farquhar, stepped down as co-CEO of Atlassian and the other major announcement was a drastic change of Jira as a product. For more than two decades Jira has been closely connected to development, which as even in the name up until the big change in 2024.
On stage Mike Cannon-Brookes announced that Jira Software was dead. There were no more software product in the Atlassian product line, but instead a new product called just Jira was born. This new Jira seemed to be the same, but with new functionality such as Goals and Projects taken from Atlas, another Atlassian product and a complete merge of Jira Work Management, making the new Jira less of a development tool, but now a more capable multipurpose tool to fit many different ways of working.
Massive changes to navigation and functionality were announced, and it was clear that Atlassian was moving into a new era.

The New Jira and the new terminology
For a year we have watched Atlassian change their product line by merging products together to more powerful products, but also to change the language and the way we use the tools through massive changes to the User Interface of the products. We first got the ability to rename the abused and confusing Epic to anything we want globally in our instances. This fit perfectly with the ability to extend the work item hierarchies so we can build parent child relations above the old Epic level.
Now we are getting the next terminology change, and it makes perfect sense that a word associated with problems and faults no longer should be the default wording for work, which is now any form of work. In the vision I think Atlassian is working towards with a more generic tool that can be used for any number of situations, they needed to address this very old and very bad terminology issue.
It is not something I think they do in isolation, but as a part of a far bigger strategy to reposition Atlassian and their products, which started long before the big announcement in 2024.

Work as the new collective term for all items tracked in Jira
Work as a term for what you do in Jira makes perfect sense for most people. There are people that are not actually tracking work and for them this might be weird of course. Those people are very few though and considering that millions of users have been referring to work as an Issue for two decades, I think that is a tradeoff Atlassian has no problem making. While you could have made an argument for using other terms like Task, that does not fit the overall vision of Jira I think because it is a tool used to track work and if you have tasks that are not actually work, then maybe you are better off using another tool?
Or you can just ignore the term and do what everyone have been doing for the past 20 years when we referred to work as issues.

What is actually changing?
There is an impressive amount of confusion around this change, which is actually much smaller than most people think. In the comments in the announcements you can see that people don't even read the information, and they ask the same questions as has already been asked and answered multiple times.
So let us iron out what the changes actually mean.
This is JUST a language change.
This should be obvious, but a lot of users seem to miss this. This change will replace any text you currently see using the term "issue". That means that it will change the language in the UI when users create work items, when you see listings of work items and so on. You will see this in all configuration areas for terms like Issue Types and Issue Type Hierarchy.


This will NOT change your Issue types or Request Types
Your tasks, your stories and your custom Issue types or Request Types will NOT be changed. These are data objects you have named and whatever you name them will NOT be affected by this.

This will NOT impact the API or Automations
All existing references to Issue will remain in both the API's and the automations.

This will NOT impact JQL, Filters or Boards
JQL clauses and any existing filters/saved searches will continue to support the term 'issue' to maintain backward compatibility. We'll introduce a new alias for 'work' to support the terminology updates.

In short, you can expect that everything will work just as it does today for all aspects of your Jira products. The change will be in language only and while that can absolutely confuse your users and make you a bit lost in the configurations before you get used to it, technically nothing will change.
For now.

People are upset about changing Issue to Work in Jira
It is both sad and a bit funny to see people's objections to this change as they are clear signs of personal preference and have little basis in actual logic. It reminds me a bit of the hypothetical experiment where a number of monkeys was conditioned over time to prevent anyone from climbing a stepladder to get the banana. If you have not seen it, you can see it here: https://www.youtube.com/watch?v=WkT0BtfOB-M
What most people in the comments are actually complaining about is that they don't want to change. Not that the change itself is wrong or bad, with any form of logic as to why, other than their own preference or what they are accustomed to. This is perfectly normal because humans do not respond well to change in any situation and when you change terminology in a working tool you use every day, then that have a pretty big impact. I think most of the people complaining are also suffering from stress so they don't really have time for new changes like this.
As this rolls out however I think people will realize that this change is not as big as they think. People still will call work items in their own way, and we will hear people telling others to "create a Jira" or "create a ticket" or some variations of those after this change anyway. Considering how many have complained that it more complicated to ask someone to create a "work" than an "issue" says a lot on how some people refer to their work in Jira.
I would suggest to start using the name of the work items you have actually created instead.
"Can you create an incident" or "Can you create a story" makes a lot more sense to me, plus you don't have to answer the follow-up question that you inevitably will get if you refer to the term and not the work "Which issue/Jira should I pick?". But, use whatever language you find to provide the best clarity of what to create and how to refer to your work.
As long as everyone understand each other, then you should be good.

Jimi Wikman
By 💫 Jimi Wikman in Atlassian ·

The New Atlassian Navigation and the thoughts behind it

Atlassian General, Confluence, Jira, Jira Service Management, Jira Product Discovery,
As we are moving into March, more users will experience the new Atlassian navigation for the first time. Some of them will love it, some of them will hate it. Regardless how they feel, they have to get used to it because it is the new standard that we will see in all Atlassian products. Considering that Atlassian have already tried a sidebar main navigation before, and it was quickly changed because it was universally hated, why are Atlassian rolling this out again?
The answer can be found in this YouTube clip where Kristin Perchal go through the reasoning. This is a recap I believe from the Webinar (hidden behind a sign-up form) called Unpacking the new Atlassian global navigation experience. Kristin is doing a great presentation to explain the reasoning, so let us break them down.

The Problem the new Atlassian navigation need to solve
The Atlassian Mission "Unleash the potential of every team" and the fact that a lot of user have complained that finding things in the Atlassian products is a problem. In fact measurements show that 40% of the time spent by knowledge seekers are spent finding information in the products. The phrasing is interesting because I doubt anyone working in the tools spend 40% of their time trying to find things, so I assume what is meant here is that we spend more time finding things when we are looking for it than the fact that the navigation is bad. This has more to do with how well the users understand and know the products.
33% of the negative CSAT feedback relates to navigation and findability. Again, this goes more towards understanding the products, but also to a more interesting problem: Inconsistency.


Inconsistency in the Atlassian products
"Our product portfolio has expanded and each of the products have evolved separately, resulting in inconsistent navigation experiences across products."
This is a very true statement, and it is not just affecting the navigation and findability, but also impact the language and functionality. Teams is one such area as well as the use of the word Epic in different tools. I think this is by far the most important reason for changing the navigation and for doing so across multiple products. We also see Atlassian absorbing external platforms like Opsgenie into the standard products, which also help align consistency and increase the value of core Atlassian products.
I like that Atlassian is focusing on this and that they are working on language and functionality, even though I think their internal organization and their commitment to Agile methodologies are challenging for them. I look forward to more initiatives like this to remove bad language and align products and functionality consistently across all products.


Industry behaviors and standards in Atlassian navigation
"Our navigation lacks modern behaviors and standards that our competitors provide like
Reduced cognitive load aka clutter
Improved efficiency in completion of tasks
Alignment to other common patterns to reduce the need to re-learn behavior/pattern when you use Atlassian tools"
I am not sure these statements are true because the clutter is very much there and the readability has not improved, especially with the light font and iconography that provide little guidance for the eye. I also do not think the findability improves much unless people were having problems finding functions due to the navigation itself, which is not my experience after teaching thousands of users. The problem is naming and understanding the tool, not to find where the link to a function is located, but that is a topic for another time.


Scalability in the Atlassian navigation
"Consistent design and familiar industry patterns across our product suite that support the evolution of bringing our products closer together and service more team's use cases than ever before."
No matter if we like the design or not, it is a good thing to align into a consistent design pattern. If the future show that this is not the right way forward so we see a repeat of the Blue sidebar navigation in 2018, then a change will be done across all products, and it will be consistent. This is very good.
Will the sidebar design scale better than the top navigation? Yes, I believe it will, even if it will be a challenge to keep in from cluttering. I am curious how they will tackle the secondary navigation that is now horizontal (so we have basically switched directions) as I see that navigation is already at risk of overflowing.
Overall the sidebar design should provide better scalability, but there are of course disadvantages to this as well as you risk pushing navigation areas out when the navigation tree becomes large enough. The amount of sub-nodes in the navigation is also an issue as they are now quite many in some areas.

The solution to solve the problems for the Atlassian Navigation.

A solution for how you work, not the other way around
"New customization capabilities for each user's unique way of working and individual preferences."
This is where I chuckle a bit because this is Atlassian in a nutshell these days. They want the cake and eat it too. What this refers to is the functionality in the new navigation to reorder and hide parts of the navigation so you get your own structure and your own navigation tree. If you are changing a navigation pattern with the desired outcome is to provide a more consistent experience, how is this aligned with every user having their own navigation structure and their own content in the navigation tree?



Yes, the functionality for each node is consistent, but the navigation now moves from a consistent per product design to a variable solution on an individual level. I think this will introduce a lot of confusion and for content creators and product trainers this will add another challenge where our navigation structure may look very different from the users that rely on our content or trainings.
I already have seen a few cases where people get upset because they can't find something in the navigation because they forgot that they hid it from view, or because they have moved it and forgot about it.
On the upside though I know a lot of people like this, especially the early adopters. The question is just if it will add more value than frustration across the entire user base.

Enable Teams to stay in the flow with the new Atlassian navigation
"Improve user efficiency and customer satisfaction by aligning to a pattern users are familiar with while paving way for an AI-first experience."
The idea to take experiences from other tools to reduce cognitive load does not really make sense to me, because the top navigation is a well known pattern. Not having to jump back and forth and having more room to expand the navigation than in a top navigation makes more sense to me. The downside with a sidebar navigation that expands however is that once your navigation become long enough you will effectively push navigation areas out of sight, which can have negative effects.
The top navigation can use the "More" functionality so it breaks off the navigation nodes that can't fit, which has its advantages and disadvantages. I don't think the sidebar navigation will be better or worse in that regard. The visibility is a bigger concern, but that can be enhanced, perhaps with a selection in the personal settings.

A modern look and feel for the new Atlassian navigation
"Revitalize the navigation by delivering a fresh modern product experience"
I have always despised these buzzwords because there is no such thing as a "modern" anything and when you add fresh, it just means they wanted something new. Nothing wrong with that, but just say that you were bored with the old design and wanted some new eye candy.

The result from user testing the new Atlassian navigation
The webinar show some impressive stats, but without the actual data on how those numbers came to be. This is typical when you want to hide the actual data, or when you don't want the viewers to focus on the metric, but the message.
For example 97% stayed with the new navigation once they had it, which makes sense since this will be the new standard. There is no advantage in reverting, unless you are just so disgusted that you absolutely can't use it, or you want to stay with what you know a little longer. These tests were done in an EAP and later in an open Beta, which means you got the early adopters taking the tests. Still, it is a good indicator that we will not see the repeat of the blue sidebar mistake.
Stats without any data attached to them are thrown in for good measure and I would take those with a grain of salt since we don't know the metric for those.


More Active Users
More Active Teams
More Cross product usage
More efficient navigation to progress your work

Considering the claim that users spend 40% of the time spent by knowledge seekers are spent finding information in the products, it would be strange if these things were not true, but the question is what are the measurement points and to what extent are these arbitrary measurements measured?

When will the new Atlassian navigation roll out?
This has been a bit of a mystery because it has not been published anywhere as I have seen. You can only see this roadmap in this webinar and even there it is noted that dates are subject to change. There are five dates in this roadmap, starting with the EAP and Open Beta that started in October last year, and it ends with full rollout in September 2025. Here are the dates and when you can expect to see the new navigation in your Atlassian products.

March '25
Start rollout for Standard edition
All Free Edition
All new Trials
Opt in for all Sandboxes
July '25
Start rollout for Premium edition customers
September '25
Start rollout for Enterprise edition
December '25
100% all customers on new navigation

What is my impression of the new Atlassian navigation?
My personal impression of using the new navigation for a few months is that it is not bad, but as a long term user it takes longer now as I am not familiar with the new icons, the new structure or even where functionality is located. I often find myself scanning the tree trying to figure out where in the tree I am currently at and then trying to find out where to go to find things like board configurations as those are a little hidden.


I think that the users that have working in the products will have their productivity go down initially as they have to re-learn patterns. This is normal when you change navigations and it is a temporary issue. It is however something you need to take into consideration for when the new navigation is rolled out for your organization.
I also believe that this change will see a good amout of resistance, but that this resistance has more to do with the human nature to resist change than that this new Atlassian navigation is bad. As a UX designer and experienced user of the Atlassian products I have opinions, but as with all design opinions will always differ and at the end of the day it is Atlassian that have the final say if this new Atlassian design fit their vision of their products.
I also find the clarifications on the design decisions, not just in the video where Kristin Perchal go over the business decisions, but also in the article by Tarra Van Amerongen, Head of Design Jira Platform where she go through the design decisions in a very nice way. The article is named Designing Atlassian’s new navigation and you can find it in the Atlassian Blog.
Comparing this with the old blue sidebar, which was not received well, I don't think we will have the same issue with this design. The old blue sidebar had a very bad navigation switch system, which we still have for Jira Service Management by the way, which switched the navigation with a new navigation. This was very difficult to navigate and you often got lost, not really knowing on what "slide" of the navigation you were currently on.
Back in 2019 when Atlassian changed from the blue sidebar to the top navigation people where very happy necause the experience was very confusing. You can see the comparison between the old blue sidebar and the new cloud on this page written by Rachel Wright on her excellent website Strategy for Jira.
I don't think we will see the same situation this time, but that all depends on how vocal people will be about resisting this new design for the Atlassian navigation across all their products eventually.
Overall I am positive about this change and I think it fit well into the new direction I think Atlassian is heading where they are tightening their product portfolio and rather than selling products they are aiming for one product with multiple modules...


What do you think?
Jimi Wikman
By 💫 Jimi Wikman in Atlassian ·

Opsgenie end of life on April 5th, 2027

Opsgenie,
Today Atlassian announced that Opsgenie, the On-call and alert management tool that has been widely used for Data Center customers and Cloud customers alike, is being decommissioned. The first end date is end of sale – effective June 4th, 2025 from when no new licenses will be available. Then on April 5th, 2027 there will be no more support for Opsgenie.
This is of course devastating news for many Atlassian Opsgenie customers as they now will have to find new solutions for their on-call and alert management. If you are on cloud, then you will find that almost all functionality from Opsgenie is already in Jira Service Management, and you also have a few extra features like automations. While tricky to fully migrate everything, as long as you are on a cloud instance with a Jira Service Management license, you should be fine.
For those of you that are using a Data Center solution however, there does not seem to be a plan for you. The migration tool is only for Cloud and as far as I know there are no solutions for you on Data Center that can replace Opsgenie.
I don't know how Compass is included in this since it is not an on-call or alert system, but I do know that since Compass is a cloud only product, it will not help those of you with Data Center instances. It is a bit unfortunate that the blog post where Atlassian present their thoughts on why they shut down Opsgenie is written clearly from a cloud perspective as it does not even mention the Data Center clients.
I don't know if there is a plan to announce that Opsgenie functionality will be added to Jira Service Management for Data Center as well, but I think if that was the plan they would have added that in the blog post to avoid the angry customers that no doubt will complain about this (and rightfully so).
UPDATE: Atlassian have added this to their Migrate from Opsgenie FAQ for Data Center Customers
As part of its cloud-first strategy, Atlassian has been working to embed Opsgenie’s functionality across the Atlassian platform and products. Since Opsgenie is a cloud product and does not have a Data Center deployment available, Data Center customers will have a two-year period to plan and carry out their migration to either Jira Service Management or Compass to retain functionality like alerts and on-call management capabilities.
Personally I think this is a good thing to move away from standalone products and merge things into the platforms. I also think this shows the way Atlassian sees the Data Center customers, even if I think we could ascertain that Data Center is not a high priority for Atlassian.
At least not at the moment.
Jimi Wikman
By 💫 Jimi Wikman in Atlassian ·

How do you secure your API for Jira Data Center to control what data flows in and out of it?

If you are serious about keeping your Data Center secure and high performing, then making sure your API is not being hammered and that data is not moving in and out of the API without your control.
In Data Center, we can control what is happening in our API in several areas:
Account - allow us to control what accounts have product access and can create tokens to be used to connect with the API
Rate Limiting - allow us to define what connections we allow and how many calls they can make before they get throttled.
Allow list - allow us to control from where we will allow connections.
 
Account
The first thing you want to do is make sure that you control the accounts used to connect to your API. You do this by creating local accounts following a special standard, so you set the account name and email. This will ensure that you are in control of the account and no one can access it or reset the password to gain access.
Example:
Username: SAINT001
Full Name: SAINT001
Email: SAINT001@yourcompany.com
Once the account has been created, you log in as that user using the Switch user function in the User Admin section. Go to Profile ⇾ Personal access tokens and create a token for that user. Make sure it expires in 6 months, or a year. The length depends on how often you want to set up the review of all integrations to make sure the integrations are still active and the documentation of the integration is up to speed.
 
Rate Limiting
Rate Limiting have two purposes in our setup: limit the amount of requests that integrations can make to prevent performance issues and to control what accounts can access the API.

Enable Rate Limiting and set it to Block all requests. If you have an old Jira with a lot of unknown integrations, or if people are treating it is a playground, then first set it to Limit Requests. This way you can turn down the number of requests, so people notice that something is happening, so they contact you about it.
This is assuming their integration actually has been built with response management and rate limiting support, which they should if they know what they are doing. If they don't, then they actually pose a danger to your Jira, and they should not connect to it anyway.
Once you have activated this, and it is blocking all requests, then no one can access the API. This is not what we want, so we add all our integration accounts to the Exemptions list. This will allow those accounts to connect to the API again.
Set the rate limiting to whatever limit makes sense in general, depending on the configuration of your hosting hardware and perceived impact from the number of integrations you have. If you see that an integration account show up in the List of limited accounts repeatedly, then talk to the integration owner and see if there is a problem, or if that integration need a more generous rate limit.
 
Allow list
The Allow list will give you the ability to further control access to your API by preventing access from any source that does not match what you have defined. This prevents someone from gaining access to one of the integration account to connect from outside what you have defined.
It also prevents users to share their integration account and token with other groups in your organization, which you should absolutely not allow.
The Allow list should be activated, and the settings should be set to allow authenticated users. You can then add domain names, exact matches, wildcard expressions and regular expressions. Be careful when adding wildcard expressions since users will often request whole networks and that will reduce the effectiveness of your allow list.
Always be as specific as possible. This means that it is far better to add a dozen specific endpoints than adding a wildcard for a full subnet.
 
Access to data
As a Jira administrator, you should have no involvement when it comes to managing access in Jira. All licenses should be managed by your AD, even if you are a small company, and all project access should be managed by the teams that work in those projects.
This is very important because if you are responsible for licenses and project access, then you are also legally responsible for how the integrations handle the data they have access to.
 
Make sure that all Jira projects are hidden by default!
I know that sharing is caring, but oversharing is not something you want to spend time in jail for. Make sure that all projects have the same settings for this, and that is that all Jira projects are hidden unless you have a role in that project.
This ensures that integrations also can only access the data that they have access through by the teams manually giving that account a role in their project.
If you absolutely must have everything open to everyone in the organization, but still want to restrict the integration accounts only, then that can be done with AD groups. Just assign all employees in the organization an AD group, and then use that in your permission settings to give all employees access to every project.
Since the integration accounts are local, they will not have that group (unless you stupidly add it of course, but that kind of defeats the purpose of having it...). This way those accounts still need to be assigned a role, and you are able to control the data they have access to.
 
Secure, Compliant and responsible
These three simple words should always be your mantra when you are working as an administrator in Jira and for integrations they are extra important.
If you do not control your API's, then you not only risk exposing things that should not be exposed. This can be secret projects or god forbid information about your internal infrastructure or customers that a malicious hacker can exploit.
You also risk legal actions based on how the information your Jira provide to other systems, should they use them incorrectly. While Jira in itself do not handle a lot of sensitive data, the tickets themselves can have a lot of this, especially if your users have requested custom fields that hold this kind of information.
And finally, I think everyone can see that if anyone in your organization can connect to your API and do whatever they want, there is only a matter of time before this will start impacting performance.
At the end of the day, it is your job to make sure your Jira is Secure, Compliant and that you configure it responsibly.
 
--
These are very small steps you can take to secure your API access, and there are other ways as well. Do you have additional steps on how to secure Jira API, or do you think this is not the way to do it?
Sign off in the comments!
 
Jimi Wikman
By 💫 Jimi Wikman in Atlassian ·

Assets - the lost potential

Assets,
I remember when I first saw Insight in the Riada office and I was blown away by the potential. When Insight was split off into Mindville later I thought that Insight would take off like a rocket. And it did so well that Atlassian eventually acquired Mindville. I had no reason to think that Insight would not become a new product with Atlassian that would rock the world, but I was wrong. Very wrong.
In July 2020 Atlassian announced that they acquired Mindville and thereby took ownership of Insight as a product. Since then things have moved on for the Data Center version where things like improved UI and Auditing have been focus points, making it an even better administration tool for Jira Administrators.
For cloud... well, it has been pretty dead in the water.
Sure it has the base functions, but there are so many things missing!
Differences between Data Center and Cloud.
Import data types
Cloud: CSV, JSON, Assets Discovery
Data Center: CSV, JSON, Assets Discovery, DB, LDAP, Jira Users and Groups
Integrations
Cloud: Jira Service Management Services, Marketplace Integrations for Cloud
Data Center: Cloud providers (AWS, Azure, Google Cloud), Mobile device and software management (JAMF, SCCM, Snow), Other CMDBs (ServiceNow, Device42), Atlassian ecosystem (Jira & Bitbucket, Confluence, Tempo), Others (NVD)
REST APIs
Cloud: Public REST API, External Imports API
Data Center: Public REST API
Object schema templates
Cloud: Coming soon!
Data Center: ITSM, HR, FM
 
There is more...
While this just show the high level differences I think you can see that there is a substantial gap in high level functionalities. In addition to these changes we also miss features like the ability to upload scheme specific icons and automation. There is also no file management for CSV imports and so on.
 
The Gap is not the worst part...
While having a big gap between Data Center and Cloud is bad, there are other things that in my opinion are even worse and that is accessibility. I don't mean the UI, but the fact that on Data Center Assets is available for free, while on Cloud you have to double your annual cost and go premium to get your hands on it.
The fact that a single agent license cost a whooping $47 (compared to Jira Software's $15 per license) is cause for many mid-sized to large companies to immediately regret trying out Assets in Data Center.
This cost and the fact that you can not even try it out in a limited capacity make Assets something that only those willing to buy on a leap of faith, or people that already have experience with the product, to actually experience it. This is the same problem that Atlassian have with Jira Align and I think it is also why both Jira Align and Assets are growing a lot slower than they should.
Assets as a Jira System Administration tool is amazing
If you have used Assets on Data Center or Server, then you probably already know what an amazing tool it is to keep track of your Jira system. The Jira environment import not only spider though your system and keep you updated on changes, it is also a very nice one stop database for all your administration needs.
It will allow you to keep track of all integrations, service accounts and anything else that you have that is not directly included in the import. If you have a messy system with a lot of technical debt from migrations and things like that, then it is an amazing tool to keep track of what you need to clean up and what you should consolidate.
It also provides a very useful tool for your support desk where you can connect all tickets to existing configurations. For example, you can connect all configuration requests and automatically assign an approval to the project lead. This speed things up and you can simply ignore tickets that are not approved, seriously reducing time you spend on tickets.
If used correctly you can also connect all tickets to the configurations involved. This type of historical documentation really help to maintain your system well-kept and organized.
I hope to see much more development on Assets Cloud
I really, really like Assets. It is one of my favorite features for Jira Service Management and as such I really, really hope we will see a lot of improvements when it comes to the Cloud version. The Jira environment import is a must I would say, but also AWS and Azure import is really, really important. I think many will also miss both Tenant and Yamf imports.
When it comes to the Jira environment import it has some areas where it should absolutely be adjusted. For example, you should be able to follow the full chain of configurations regardless of starting point and there is no Permission schema, which is odd on Data Center.
The road forward if I was in charge
I am no fan of the forced Premium features that Atlassian have. I think it goes against their core values and I think you should be able to explore all products regardless of subscription level. So what I would do is either break out Assets as its own product or add it for free with limitations in the free subscription tier.
If you can make 3 schemes and only have 1000 items in each for free, then more people will want to try it out. More people trying it out means that more people will see how useful it is, and more people will want to get the full version. More people means that more companies will build more apps for it... and so on.
--
Well, for now I will continue to enjoy the amazing features that Jira environment import provides on Data Center. I hope that one day I will not only consider moving to Cloud, but actually yearn for it!
Let's get Assets on Cloud Amazing!!
Jimi Wikman
By 💫 Jimi Wikman in Atlassian ·

Let's build a two site support setup with Atlassian Products - part 1

I currently own two websites, atlasstic.com and jimiwikman.se. and I want to set up support for both of them. I don't want to spend a lot of money doing so, as I have other things to sink my money in, like hosting for example. So I want to set up a dual support using just one license. To make this a bit trickier I want to make it so that the two setups will feel and look completely different.
So let us plan this shall we?
So I have one Jira Cloud instance and one Confluence instance. The Jira instance is a premium license, because I want to play around with Advanced Roadmaps. I have a standard Jira Service Management on top of that and my Confluence setup is also a standard setup. I want to take advantage of all the Atlassian products I can, so I also have Jira Work Management, Jira Product Discovery, Compass, Bitbucket, Status page, Trello and Beacon. So I have a pretty extensive toolbox to play around with.
My Key add-ons at the moment are Refined that I will use to split the support portals, Scriptrunner for all kind of magic and Microsoft 365 for Jira for all email/teams/Jira combinations. I am also running BigPicture Enterprise and StoryMap for planning and for making some videos.
One Support project for both sites.
The core of the support setup will be one Jira Service Management project where all tickets from both sites will aggregate. This makes sense since there are not a lot of tickets flowing in. If I want to split this later on that will not be a big problem as Refined allow us to make these changes quickly and with ease.
I want to show open incidents and tie in Status Page to show on the portal. I also want to display Confluence pages to answer common questions, but as a content block and to show when a user writes a ticket. Since I have two sites I want to have this with two sets of projects and spaces.
For support, I want to have different types of requests depending on what the person submitting a ticket for wants. I also want SLAs to measure my response and resolve times as well as timers to help count down and remind customers automatically in different time intervals. I want to automate the status transitions during conversations so I don't have to change the status manually every time.
Let us plan the project setup
The first thing we need to do is to plan the issue types so we know what kind of requests we want to handle. While you technically can use any issue types as you will define the actual ticket types, there are some nice features built into Jira Service Management that we can use.
ITSM is a pretty good standard for must use cases and in Jira Service Management we can add those under Features in the project settings. So in the Work categories section we will activate Service requests, Incidents, Problems and Changes. We will also activate post-incident reviews but mostly to try that out rather than it being anything we probably will need. As I don't have Premium I can't activate Customer Service Management, so we leave that one for now.
 

Now that we have these activated we will get extra sections in our project that act as Queue categories, which is very nice. Since we have these defined now as sections, or categories really, it makes sense to also have these as our issue types.
The next step will be to map the different request types towards these sections.
Planning Request Types
The first thing we need is something for when people email in. This will allow us to separate these from other requests as the quality of these are usually very poor compared to portal created tickets that we can control the content from. We also need an incident type, so people can report problems of course. I do get some collaboration tickets also of various types, so we need something for that. Suggestions sometimes come in as well and we want those to go to Jira Product Discovery for processing. Legal is always good to have in case we get requests or demands from legal sources.
So, let us break that down into actual request types:
Incoming Email Incident Collaboration Suggestion Legal General questions I think that will be a good start and then we can build upon that later when we see the need for it.
Asset Management
I love Jira Assets and I work extensively with it in my role as Atlassian Platform Owner at Sinch, but in order to use Assets I need the premium version of Jira Service Management. At $47 monthly for just one Agent that is a bit much, so we will settle for the very limited Services feature for now. It is not a very good feature compared to the actual Assets product, but it will work for connecting tickets to the different parts of the two websites.
Create the project
Based on this we can go ahead and create the project. We could go for the ITSM template, but it adds a lot of things that we don't need that we just have to clean up later, so we go for the blank project for IT teams instead. In the screenshot below I had to add another Key since I already have this setup. I choose company managed because I like structure and order and I do not like team based projects.
Now t
Now that we have the project it is time to tweak some things and I started with the issue types. I decided that I would change them up a bit and this is the list I can up with.

As you can see I have created a new Issue Type Scheme since I like to name things so they look good rather than having generated names. On top of the four standard issue types that comes with ITSM (Incident, Problem, Service request, change request) I also added one for Post Incident Reviews since we have the feature activated. I also added Ask a question for more open type and then Consultation for collaborative things. Finally, I added one issue type for Email request as well.
From there we can now begin creating the request types and the forms we want to go with each request type. I just add them one by one and map them to the request categories and issue types.

Most request types end up in Service Request, but we get a few in each except for Problems. This is fine as problems are internal tickets.
Building the Request Forms
I like my tickets clean without too much clutter, so when designing the request forms I go super simplistic and then I can add later if I need to. I also like to use Forms since that allow me to ask for any type of information without adding a ton of custom fields.

For the request form itself I always make sure I have the Summary field, even when I work with Forms. This is because the summary is what trigger the suggestions from Confluence and it also ensures that I get variations in the summary instead of having them all the same if you choose to hide it.
At the bottom you can see that I have added a form to this request type as well, which we will cover in a different post.
 

For the Issue View I just have the Description and Summary in the top section for this and then I add the fields I feel I want for this request type. I did add tabs for this project and I will show how I did that in another post so you can see how that looks and what you can do with it. Adding the tabs require you to go to the Screens and this article is already a bit long.
Since we do not have that many request types I will just add two Portal categories, one for General requests and one for Incidents for now. We will experiment a bit with this in Refined later so we might come back and adjust this then. As we can place individual request types in Refined rather than just display the project setup, this is not as important as if we had not used Refined.

Now that we have our issue types and request types setup we need to create the workflows and set up the automations we will use. This is the topic of the next article, so if you like this so far make sure you keep an eye out for the next chapter.
This is a rather high level article, so let me know if you want me to dive deeper into a topic in another article.
Jimi Wikman
By 💫 Jimi Wikman in Atlassian ·

There is a problem with Jira Service Management escalations...

If you have worked in a larger company you probably have noticed that escalation between the different support tiers cause a lot of problems. Perhaps you even notice this in medium or even small companies as well. The reason for this is that Jira Service Management is missing functionality that is needed for escalation to work properly. For a tool that claim to be an ITSM tool, this is quite strange, but well in line with the way Atlassian thinks about their products.
If you are unfamiliar with ITSM and support tiers, then I suggest this nice article as a starting point: https://www.bmc.com/blogs/support-levels-level-1-level-2-level-3/. If you don't want to read all that, then the short summary is that in ITSM support is set in multiple levels of technical expertise.
It starts with a basic support, which is to answer the most obvious questions and to make sure the tickets have enough information. Then the tickets Tier1 can not solve goes to Tier 2 which have more technical knowledge and so on. You can have as many tiers as you want, but most models have 3 or 4 where the last tier is outside help towards vendors for example.
Jira Service Management does not support collaboration
This might be a strong statement, but in this case I feel it is actually true. Maybe we should say handovers, which is what we are actually talking about, but since communication has to remain constant towards the customer I feel that this is still true.
So what am I talking about?
In Jira Service Management today there are hard boundaries around the projects that can not be bridged without harming customer experience. What I mean by that is that in order for me to hand over a ticket to another team I am restricted to 4 options:
Have everyone working in one giant monolith project. Move the ticket to another project. Clone the ticket to another project. Create a linked ticket to another project. Before we dive into what these 4 options mean, let us first define what our customers expect from the interaction with support. From a customer perspective they have a problem, or a request of some sort and they have done their job by submitting a ticket to support. They now expect support to handle their request and solve their problem in that ticket. This is a fair expectation and if we break this expectation they will experience frustration.
1. One Monolith to ruin it for all
This is by far the most common way to work in small companies and it is how Atlassian envision us using Jira Service Management. One box where everyone that needs to be involved have a role. The problem with this setup however becomes very apparent when you start to grow as an organization, or when you start to have multiple products and services with shared resources.
Not only will there be a lot of people in the project, perhaps several hundred people or thousands even if the organization is large, internationally distributed or need to handle multiple companies setup because of company structure or acquisitions. To be able to make sense of a large instance with many teams you need to make a lot of queues and this is where the first problem is with Jira Service Management today: There is no nesting of queues. You have to get an add-on to handle that, which add cost to your already quite expensive platform.
The second problem is that when you mix many teams in one project, you will start to add complexity as the various teams want to customize their experience. You will start to build automations with multiple exceptions, you need to start adding local groups with all the problems that come from that and you will have subsets of screens connected to customized issue types and... well you get the idea. It quickly becomes messy and soon you will have manuals for how to work based on what type of request for which team you are working for to navigate all those custom fields that confuse everyone.
This is a horrible way of working.
If we instead work with Jira Service Management where we have an IT Support desk for first line support (Tier1) and dedicated projects for Tier 2 and Tier 3 teams, then we are in a much better place. But there are still issues...
2. Move ticket to another project
Our first option when not working in a monolith when we want to hand over a ticket to second or third tier teams is to move the ticket to their project. It makes sense technically because the tier 1 team will have no more involvement with this ticket and it should not be handled by another team.
From a customer service perspective it is a terrible option, however. Not only do you break all old communication because by moving you are now changing the URL and the ticket ID. This will make all old communication useless because links will not work and the poor customer no longer can reference the ticked ID as they now have a new one.
Technically you also have permissions to consider and if you do not have the same setup the customer can lose access to their ticket all together. The information in the ticket can also vanish if you do not use Forms and the custom fields are not the same in the projects.
Any SLA you have will also be ruined since each project have their own SLA and when you move a ticket the SLAs will be reset as they are counted again with the new SLA in the project they are being moved to.
In short: Never move support tickets if you can avoid it.
3. Clone the ticket to another project
This is an even worse solution than moving the ticket. Not only do you get all the negatives from moving the ticket, you also duplicate the information. This means that the customer now have two identical requests, but you also have different statuses and different communication. If you for example clone the ticket and then close the initial ticket, the customer will get a notification that their request has been closed, which will confuse the heck out of them when they then get a reply in a ticket that look identical, but with a different ID and different URL.
In short: Never clone a support ticket unless you REALLY want to frustrate your customers.
4. Create a linked ticket to another project
This is very similar to cloning the ticket if you are doing it wrong. That would be that you create a linked ticket and assign it to the customer. Then it would just be a cloned ticket you have linked.
Used correctly however that creates a separate conversation between the two teams. This is how it should be used in Incident Management for example where we need activities to be performed in development or Infra teams for example.
This will not help us in our scenario where we want to make a handover, however as the customer conversation still will be in the original ticket. We could build an automation that sync the conversation between the original ticket and the linked ticket, but since that will be posted as the actor in the automation communication will look very bad on both sides.
We will also still have to keep the original ticket open in the project for the Tier 1 team, even though they no longer have any involvement. The customer experience might be ok, but the setup will clutter up the queues for the Tier 1 team. The Tier 1 team will also be responsible for the SLA, which means that they might unfairly get bad SLA results because of the Tier 2 team activities.
In short:  this is probably the best option, but it is not very good.
 
How do we solve this then?
Without knowing the architecture of Jira Service Management the suggestions here might be more or less difficult to accomplish, but I will make the suggestions based on the customer experience and UX rather than architecture.
1. Change Queues to allow tickets from any project
I can not for the life of me understand the architectural decision to restrict this when boards have had this functionality forever. Just this small change alone will make Queues so much more useful and it will allow teams to work with multiple requests from one area. Queues for Jira Service Management have the right idea, but they focus on local groups, which any sane Jira Administrator avoid like the plague, especially if they already sync users with the AD.
Make Queues like boards so they can be attached to projects or a user. Not only will that allow teams to work cross projects, but it will also open up for different views that can lead to add-ons or native improvements to how support in general can be designed.
2. Add account sync to automation
It would be very nice, not just for thise scenario, to be able to synch comments WITH the account that made the comment rather than using the automation agent as the author. This will allow for a better customer experience and it will make many types of setups feel more seamless than it does today.
3. Build a native handover function
While we can work with custom fields to handover ticket between queues if we get the change to queues to allow data from any project, I would much rather see a native function in Jira Service Management. The reason for that is that it would allow extending that function with more innovation and standard functionality.
The way I envision it a customer agent would just click on a handover link or button and then get a screen like the move screen. There they can select what project they want to hand over to and possibly what team. A comment field can be there by default if they want to add an internal comment as well.
When the support agent submits the ticket is flagged as handover and in their project it will no longer be visible by default in the original project (as it has been handed over). There should be a way to set up a queue to see all handover tickets however if that is wanted. This action will also trigger a new ticket in the project the support agent handed over the ticket to.
What makes this different from just a linked ticket then?
The first change is that the handover ticket work like a cloned ticket with the same information as the original ticket. This means that reporter for example is the customer and not the support agent as when you create a linked ticket.
The second change is that all comments are synced between both ticket with the account information on who made the comment. This way the communication is seamless from the customer perspective and the support agents. It also means that everything is synced toward the original ticket, making that the master regardless if the ticket has been handedover due to escalation.
If the handover ticket is handed over, then the same steps should happen, but the sync should now be done twice, once for each of the tickets in the chain.
What about the workflows?
This is a problem as many teams what to have their own workflows. As we can not, or want to, force people to have the same workflows, we need to figure out what status we will show to the customer. Each ticket will of course show whatever status the team put it in so they can follow their workflow in Jira Service Management, we just need to consider what to show to the customer in the portal.
I can think of several ways to solve this.
The first solution is to just add a label instead of using the workflow. This label can just say Escalated for example and the label stays until the ticket is closed. It is simple, but perhaps not the best from a customer experience perspective since the status actually is communication.
The second solution is to choose either the original ticket workflow or the handover ticket workflow. This can cause some strange scenarios if there are many different statuses between the original ticket and the handover ticket. Having status change from in progress to Open or New for example might be a little weird. While that can be fixed with not changing status from the original ticket to the handover ticket until it has moved at least one transition, it is not fool proof and can be confusing.
The third option is to treat this as some form of integration so we setup a mapping between different projects. This would be a massive thing to build and a pain to manage, but if done well it could probably be used for other things as well. This require you to do a lot of work also every time a new project is added that you might want to handover to.
The fourth option would be to present a choice when you transition a hand over ticket with the combined list of statuses from the original ticket or the handover ticket. It is messy and pretty much the same as #2, but less useful.
There are of course more solution to this, so if you have a good suggestion, please add it in the comments.
Communication must be taken seriously
Regardless how we look at support and what solution we prefer for escalating to other teams, we must remember that communication is key. No matter how good we are at solving problems it means nothing if we agitate the customers by not communicating while we solve their problems.
By breaking communication in any solution we have today, or forcing teams to be suboptimal by working in monolith projects we are limiting the potential of providing exceptional support to our customers.
I think we should take this seriously.
What do you think?
Jimi Wikman
By 💫 Jimi Wikman in Atlassian ·

Related Pages for Confluence - discovering content just got easier

Related information has been used on written content since it's inception, and now Confluence is adding functionality for this as well. It is a feature that not always is welcome, however, but don't worry, you get plenty of control to decide if it should be used or not. Not just per space, but even down to page level.
While we don't have specifics on the algorithms that make this new Related information work, but we can probably assume that labels and keywords in title and headers in the content is used somehow. We do know that the related pages will honor permissions, so you can only see pages you have access to. The official information have this to say:
When this rolls out, it will be turned on by default, which may be a bit annoying. Fortunately, you can turn this off for whole spaces in the Space settings under Space settings > Related pages. You can also turn this on or off on individual pages under More actions (•••), then Advanced details > and either Show related pages or Hide related pages.
In the first iteration of related pages, it will not support Blogs or Jira Service Management customer portals. While this might seem strange as these two areas are where you normally would use this feature, but I think it is a good thing as they can tweak the algorithms a bit before taking that step. This should help make that feature better when it is released. This should help a lot with support if the algorithm is good enough, which I think it will be once they get some data from Confluence usage and tweak a bit first.

 
Jimi Wikman
By 💫 Jimi Wikman in Atlassian ·

Internet Explorer is dead - Internet Explorer is officially retired and out of support

Internet Explorer is DEAD. Finally. After decades of making lives miserably for thousands upon thousands of front end developers across the globe, we can finally celebrate the end of Internet Explorer. For me, this is a great relief and yet another remnant of the Steve Ballmer area that I am happy to see put to rest. Microsoft will not put their efforts into Microsoft Edge, which like most things that has been introduced under Satya Nadella seems to be pretty good.
Microsoft has finally announced the death of Internet Explorer as they officially retire and end support for Internet Explorer 11. It has been a long time coming, and many of us old people have grown up with Internet Explorer. Some of us even remember the battle with Netscape, back in the days before Netscape became Mozilla and then re-invented itself as Firefox. We have seen Internet Explorer almost gain monopoly status, only to slowly die as Firefox and Chrome ate away the market share.
As frontend developers, many have cursed over the course that Microsoft steered Internet Explorer under Steve Ballmer's reign, always insisting on having its own quirks that forced countless hours to "fix". For many years, front end developers had to support the hated Internet Explorer 6 because it had been built in into many company solutions at the time. It was hell. Pure and simple.
Ever since, Internet Explorer has been despised for its reluctance to conform with standards the other browsers agreed upon and for the need to polyfill and CSS hack just to make websites cope with the madness.
I, for one, are glad that Internet Explorer is dead.
Now, rest in peace and long live Edge.
 
Jimi Wikman
By 💫 Jimi Wikman in Interesting ·

Upcoming changes to Epics - finally getting some flexibility for Epics

Back in December 2021 Atlassian announced that there would be some changes coming to Epics and in April we learned that Epics would see an update to how Jira manage Epic Name and Epic Summary. What does all this mean, and when can you expect to see the changes in your Jira instance? Let us dive into the information we have and see if we can answer those questions.
Why is Epic changing?
Having the ability to change, or rename rather, Epics have been requested for well over a decade and up until recently it has been ignored. It was only when SAFe started to become popular that Atlassian started to consider this, however:
This is not the only change that SAFe have initiated and for everyone working in an enterprise company where small agile teams may not be the norm, this is a positive thing. I will talk more abut that in the future.
So what is happening to Epics?
The changes are pretty big from a technical point of view, but even from a consumer perspective, there are pretty big changes as well. The reason for this big change is that Atlassian is merging features from Advanced Roadmaps into the core Jira experience. In doing so, they change the old architecture quite a bit and things will certainly move round a bit as a result.
Here is what will change:
Move issue hierarchy in Advanced Roadmaps to your admin setting Rename Epics will reflect everywhere (no more language hacks) Change what Epic fields are shown in different areas New colors based on team based projects Epic link will become Add Parent and move to breadcrumbs  
Move issue hierarchy in Advanced Roadmaps to your admin setting
The issue hierarchy that currently reside inside the settings for Advanced Roadmaps will move to the global Jira admin settings. You will find them under Issues by heading to: ⚙️ Settings > Issues > Issue hierarchy. This means that even if you do not have a Premium license, you will still be able to see these settings and when the Epic changes roll out you can edit the name of Epic from this area.

 
Rename Epics will reflect everywhere (no more language hacks)
This is a big one and the one that has been causing frustrations for many, many years. Once you rename the Epic in the Issue hierarchy, you need to rename the Epic issue type as well, and then all areas where Epic is referenced you will see the new name instead. So if you rename Epic to Feature, you will see Feature everywhere you see Epic today, including the Epic side panel in your backlog!

 
Change what Epic fields are shown in different areas
This is more of a technical change, but what it means is that what currently is shown in the backlog will see some changes. This could cause some issues that you might need to adjust when the change happen in your Jira instance.
Epic name → Issue summary
Currently, the board and your backlog show Epic Name and after the update it will instead show the Issue Summary. This make more sense, and I suspect that we will see the Epic Name removed in the future as Atlassian adjust Epics to be presented the same way as other issue types. If you have been putting different information in these two fields, then you need to update them to be the same before the changes happen. There are several solutions for this, but I think the solution Bogdan Gorka suggested in the Atlassian community using automation seems like a good way to do it.

 
Epic status → Issue Status Category
In the current solution you have Epic status, which is only available in the Epic panel, that define what Epics should be shown in the Epic Panel. In the new solution, the Epic panel will instead look at the Issue Status for each Epic to determine if it should be shown or not. If the Epic issue is in a green status (done), then it will not be shown, unless there are still open issues inside the Epic.
Again, this makes sense as it shift Epics to behave the same way as other issue types, which align behavior in Jira.
 
New colors based on team based projects
This is something that comes from team managed boards, and I am guessing this is an architectural decision to have a uniform design that can be expanded later using the Parent Link feature from Advanced Roadmaps. In Theory, it would allow you to treat any parent link the same way, and you could set any story color to the issue. To make that useful, there would need to be a change to the Epic panel to show the levels above epic as well somehow.
For now however this will just be a slight color shift when the upgrade comes as the upgrade will match the nearest color.

 
Epic link will become Add Parent and move to breadcrumbs
Perhaps the change that will confuse users the most is that the Epic link will become Add Parent and that this functionality will move from the standard locations to the breadcrumbs. This makes sense from several perspectives, but it will have a learning curve for many users. Changing the Epic Link to the Parent link from Advanced Roadmaps will once again align Epics with other issue types and allow for a uniform handling of the issues hierarchy.
 

 
 
My Opinion
This is a great change, not just because it will allow us to change Epics to Features (or whatever we want), but also from a technical perspective. It breaks down Epics unique behavior and replaces it with something that can scale, which is exactly what I have wanted for more than a decade.
In the screenshot over the new issue view you also see that there is a pretty significant change to naming for subtasks as well where we now instead see "Child Issues". This is again a way to make way for a more flexible structure that is uniform regardless of level.
This is absolutely a great step in the right direction from Atlassian and it makes me very happy to see.
Jimi Wikman
By 💫 Jimi Wikman in Atlassian ·