Atlassian Remote Summit Day 2

Well, well, well. Here we find ourselves again. Today we’ll see the second keynote and find out what else Atlassian has planned for the day. But first, do address a comment from yesterday’s post:

Maxim is correct, they certainly were cloud heavy yesterday. This is likely because most features start out in cloud and eventually make their way into Server and Data Center. That being said, you know we love your self-hosted systems here, so I’m hoping to hear what they have planned for those today. (Future Rodney here: it’s still mostly Cloud. Sorry! But we do get some Data Center and Server info today!)

Otherwise you all loved yesterday’s recap, so lets get on with an encore!

And we begin again!

Mike Cannon-Brookes does the introduction this time. He features a chrome extension that lets people watch Netflix together as a way to show how the world is already adapting to the current situation.

And he also mentioned Summit next year. I can tell you I’m already planning to go, so hopefully I’ll see you there!

Scaling the future of Cloud[…again.]

So they don’t announce it now, but it looks like there is a new cloud tier on the horizon…”Enterprise.” Hope it’s not the spaceship

Again, Finally. If I had users complain about anything with JIRA, it was about the amount of email it sends them. Atlassian claims their new method of sending digests instead of distinct emails reduces the mail spam by 30%! If true, I cannot wait!

So – this should allow Apps (plugins) within Atlassian cloud to do more. I’m excited that maybe we’ll get some of the functionality us self-hosted people enjoy into the cloud!

And it looks like they added the Premium tier for JIRA Service Desk. Seems like it should have happened sooner, honestly.

So you will soon be able to whitelist which IP’s can access your site. I can think of a few customers this would be handy for.

It looks like they also plan to bring Archiving in JIRA Software Premium some point soon. I thought new features were supposed to come to Cloud first, not Data Center 😛

Based on Automation for JIRA…I see what you did there. But seriously, I love me some Automation for JIRA, and glad to see it being incorporated.

JIRA Align is getting the ability to manage OKR’s. Being honest, no clue what they are. Sounds like a research topic to review later. But if you know – I can imagine you’re excited.

And Trello is being integrated into JIRA Align. Because you need ALL THE DATA!

So, they are adding an ability to bridge unlimited 10K instances of Atlassian Cloud Applications to support companies’ growth…

As a part of a new access Tier. Called it!

Sounds like you get some pretty big benefits from Cloud Enterprise though…

Like one place to manage all the chaos of multiple instances

Single place for user directory management, check.

Unified Billing, Check

And those sweet sweet statistics, check.

Looks like they are bringing Data Residency to their Enterprise Tier too – which could be big for government requirements.

This one is big. Rather than just getting new features whenever they are pushed, you can now delay a release for up to two weeks, and bundle them up. The ability to give our users warning will be very VERY nice.

Now I will say this. A sandbox is something Salesforce has always done better (That’s right, I’m also a salesforce admin. Bet you didn’t see that!). So it’s nice to see Atlassian start to do something for us here.

Wooo! Partners! But seriously, I’ve worked with the Atlassian TAMS and Premier support, and they know there stuff. Between them and, well, partners like me, you are in good hands.

Looks like they are making it easier to go to the cloud. That should help a lot of folks out there!

Building for change and scale (aka Data Center)

So Finally, Data Center…what have they got going on…

So – stuff they’ve done recently….I mean I’m happy for all of these features, but still….

And finally, the new things! So it looks like they are tweaking things here to improve performance in JIRA And Confluence Data Center – but the biggest one is that you can have more than four nodes in the applications. Finally!

Fun fact. A company I worked for asked for this three years ago. Glad to see it finally come!

Adding OpenID Connect as an identity provider!

Soon you will have the ability to have multiple identity providers.

And also just in time User Provisioning is coming to Data Center soon.

My Workspace One peeps back at VMware should love this.

Auditing in Atlassian apps have always been…..lacking. Glad they agree.

You can now audit user actions, not just admin actions. And it looks like this is across multiple areas of the application.

You can export these as a file log to send to ELK, Splunk, etc.

You can also delegate users to access the audit log – very much a “not my problem” move.

YES. SO MUCH YES! I’ve been wanting them to update Confluence Permissions FOREVER!

You can audit permissions for users or spaces to see who can see and do what.

This one is for server and data center. Looks like they intend to make it easier to access for those with certain impairments. I am definitely excited to see them make this move.

So moving on to new features for Agile teams…

Looks like you will soon be able to create multiple sprints quickly – while specifying dates. As a person who has had to bulk create sprints before, this is big.

Another data point for JIRA Align. Seems they are working on all the connectors!

The first thing I do in any company is figure out and document their language. Will be nice to do this in-app. And Release management love is long overdue…

Portfolio for JIRA is getting some updates to capacity planning too…

…and a Confluence Macro. This will make it soooo much easier to share a roadmap.

They already mentioned this, but it looks like they are sharing more details on the JIRA Align <> Trello connector.

And a connector for BI systems too.

I hate buzzwords, and AI is one of the worse offenders. But I promise not to judge it until I can actually see what it does…

So onto my I.T. Brethren…

I think we saw some of this in yesterday’s Cloud presentation, but it’s nice to see it come to Server and Data Center too!

You can search for incidents in OpsGenie directly in Service Desk….Nice!

As well as see a list of all present and past incidents.

Agent Queues are getting some love.

Including improved sorting, the ability to favorite queues, and bulk edits in queue. That will definitely come in handy.

This seems obvious in hindsight…if you support people who speak multiple languages, maybe come to them in their own language.

And finally, some news for developers

Looks like they are making some information about build available in Bitbucket. The real surprise here is that it’s from both Bamboo and Jenkins!

You will also be able to set build configurations per branch – which will be great for experimenting!

Looks like they are adding some more context highlighting in the diff page

As well as letting you add a comment anywhere in the diff, not only on what’s different.

And last but not least, you can search for specific files from within the pull request. Should make it so much simpler to get to what you need.

And done!

That was the end of the keynote. I’m not remembering why I only do one post a week. But it’s been great seeing what’s new. Things maybe crazy now, but it’s always important to remember there is a tomorrow, and to plan for it.

Which reminds me, you should totally check out our Discord chat. I’d be happy to hear what new features you are excited for!

If you’ve enjoyed the Keynote Recaps from the past few days, check out some of my other posts! I try to post on a wide range of topics affecting JIRA Administration, and am always up for a reader suggested topic! Also, subscribe to get new posts directly in your inbox! Sign-up form will be at the bottom of the post!

Until next time, my name is Rodney, asking “Have you updated your JIRA Issues?” I’ll check you next time!

Atlassian Remote Summit Day 1

I am so sorry for the delay…I tried to get word out that today’s post was going to be a bit late. But given when this event is, there wasn’t much choice. However, it’s an exciting day! Today we’ll start to learn about all the new things Atlassian plans for the next year.

In speaking of exciting, last month was another amazing month for the blog. And that’s with having to miss a post! Thank you all so much! Considering the events of last month, it is most definitely appreciated!

That being said, the event is starting, so lets get into it.

And we’re “live”?

Its’ a prerecorded event, but still exciting! Honestly, I’d prerecord too. No need leaving things up to chance when you don’t have to.

Try Any Atlassian Product for Free!

So, a lot of teams are having to try remote work for the first time. Given that, Atlassian has made ALL their products free for up to 10 users. So what are you waiting for! If you’ve been wanting to try JIRA, Confluence, or any other of their tools, now’s your time!

Trello Business for Educators!

Additionally, teachers are having to teach classes from afar – most of which this is there first time doing so. To support our educators, Atlassian is giving them a year free of Trello Business Class. Share this with a teacher in your life.

Today’s Agenda

Just a quick view of what to expect today – and honestly, it doesn’t tell me much. Guess I’m going to have to sit in for the full time…

St. Jude’s use of Atlassian Tools

So considering I started with Atlassian tools within a software company, it still amazes me how many companies now adopt the tool set as their default. St. Jude’s Children hospital is on that list.

Okay – had to add this slide in. Don’t worry, you’re not alone.

Software and IT Team updates! (This is my jam!)

Looks like we are finally getting into what new things to expect. If this follows normal trends, we can expect the “new, shiny” features in Cloud first, and eventually they’ll make it to either Server and/or Data Center. But still, it’s nice to know what to be excited about!

Users can customize Notification settings!

This one is big. If I had one complaint I’ve heard everywhere from users, is that JIRA sends out WAAAAY too many emails. It looks like Atlassian heard this, and are planning to allow a user level notification scheme, so each user can define the notifications they want. Unfortunately, they didn’t have a good slide or mock-up of this, so this feature may not be ready to come out just yet….but at least our woes have been heard!

Your work Dashboard (Bitbucket)

So, you know that situation where you have to jump on JIRA to figure out what issues are assigned to you, then onto bitbucket to pull the repo, then back and forth? Well, Atlassian wants to do something about it. Bitbucket will have a new dashboard that will show you all the relevant information at one go – no more context switching.

Live Status (Automation for JIRA)

So, it looks like Atlassian has some plans to make some in-place automation leveraging automation for JIRA. This will help move issues along a track based off of what’s happening to a given repo.

Here you can see an issue move through the workflow when actions are taken within Visual Studio.

While we’ve had some triggers to do something like this for a while, that was always on a pull request creation or other such event. To do it from Visual Studio by changing code – that might be big.

Code Insights in Bitbucket Cloud

So, how do you build new products without exposing yourself and your customers to potential vulnerabilities? Well, Bitbucket is building in some reviews from top vendors that will look at your code and alert you to possible vulnerabilities right away. This could be big in helping bad code not be released.

Automating Change Requests

So, JIRA Service Desk is getting some love too! Now when you have a successful test build in your build tool of choice, you can have it automatically generate a change request in JIRA Service Desk.

There is even some logic to allow a low-risk change automatically to go through, or to hold it up for a human to review.

If it’s a high risk change (as judged by the rules), it will flag it for your team to review.

And then give you all the information you need to make a decision – all in one place.

Fix Fast

So, this is about OpsGenie. However, one of the major new features is now you can now bulk-link incoming support requests to a given problem. This can save time as you don’t have to go to each one and do it. Nice!

The Incident Investigation platform seems like it will bring together information from a variety of places, allowing you to see the exact change that caused the problem, as well as who submitted it and what was changed. For some outages this can be big.

You can also do your after-action report within OpsGenie to have details about what went wrong, what you learned from it, and how it can be prevented again.

AND THEN you can export it into Confluence to share out with your team. Nice!

Roadmaps in JIRA

They’ve also added the ability to view the full hierarchy from a sub-task all the way to the epic.

And all was going well when suddenly….

The video site when down!

Kind of funny huh? The video just went down…hard. This is what one of my colleagues had to say about it.

This wouldn’t be as funny, but Atlassian was just talking about Incident response.

And we are back! So…Roadmaps?

They have added progress bars to your roadmap, so you can see how much work is actually left on different items.

This didn’t show up on the image I got, but you can also drag-and-drop dependencies on each other, so you can track what is waiting on what task to be done.

And what use is a roadmap if you can’t share it? Yes, another Confluence Macro to bring that into Confluence, then let it update in real-time!

Some more features!

So, they’ve also been getting some feedback on Roadmaps for those who have been using them.

Solution one: Add Roadmaps to Classic Projects. Seems obvious in hindsight, doesn’t it?

They are also adding the ability to create Multi Project roadmaps for those with a Premium license.

Here you can plan out across multiple teams and keep track of time frame, dependencies, and capacity.

However….you might notice this looks familiar….almost like Portfolio for JIRA. That is no mistake, this is meant to take some of the best features of Portfolio and bring it into the Roadmap.

Unify Work across all teams with Atlassian

So we are onto the final section – wonder what we’ll have here!

So we are all familiar with Confluence Templates? It looks like they want to bring that concept to more apps, including Trello and JIRA Service Desk.

For JIRA Service Desk, they will have templates for HR, Legal and Facilities. This should make bringing these teams into JIRA is now that much faster.

Finally! A template gallery so you as an admin doesn’t have to make one for scratch for a team you may not be familiar with!

New Tech? Okay, lets see where this goes…

Butler for Trello becomes a core feature one very Trello Board….and comes to JIRA and Slack!

Butler can now automatically create JIRA Issues for you when you make a Trello Card.

You can also get Butler to post a message to any slack channel! Get the word out about a new card that much faster.

Automation for JIRA

This is being brought into JIRA Cloud as we speak, bringing a native automation engine for your Projects. Which honestly, JIRA has needed for some time…

New (?) Navigation in the Cloud products

Well, they are finally revamping how the cloud products look. Atlassian won’t admit it’s the old style, and technically they are right, but looks enough like the old style that I’m happy.

Atlassian has revamped Confluence’s home page, and honestly I love this design. It’s fresh, but still has all the needed pieces within reach.

New Fun Trello Features

So, how do you add “fun” into a project management tool?

Well, you can add an image to a card’s cover so it looks more visually appealing. Having spent years looking at JIRA Boards, I can’t say I dislike this feature.

Also partnering with Giphy to add stickers doesn’t hurt. Considering the number of Gifs I use on the blog, I bet you can imagine how I feel about being able to use more of them…

Page Analytics (Confluence Cloud)

I am very much a statistics fan, so I love that we can get some analytics around Confluence page views. I really hope they move this to Confluence Server!

This has been available in Confluence Premium, but you can no access it at the standard tier now.

Confluence Editor

There are some minor changes to how links appear and how to expand sections in Confluence Cloud, but the change that has me the most excited:

That’s right, a new macro browser. The one in Confluence Server is passable, but not good, and they managed to make it worse in Cloud by throwing in JIRA Gadgets. Nice to see they put some love into this! BTW: If you are not using macros in Confluence, what are you even doing?

Inline comments in Edit mode

Just one word here: Finally.

And that’s it for day one!

So, what features are you excited about? Honestly some of the automation around Change Requests look exciting to me. Leave a comment with what you are looking forward to.

Today was very cloud heavy, so I’m hoping tomorrow we can learn more about Atlassian’s plan for Server and Data Center. In speaking of tomorrow, we’ll be back here with another post about what they announce in Tomorrow’s Keynote. Again, don’t expect it at Noon Eastern – it will likely be some time a 5-6 PM Eastern.

Until then, my name is Rodney, asking “Have you updated your JIRA Issues today?” I’ll see you all tomorrow!

Atlassian Remote Summit Scheduling

Hey guys! Just a quick heads up – Tomorrow’s normal post will be delayed. This is so I can watch the Remote Summit’s keynote and be able to give you the news about what’s new in the world of JIRA, Confluence, and all the Atlassian tools.

Unfortunately the keynote starts 30 minutes before I normally release posts – there is no way I can write that and get it up here with any kind of quality. So I’ll be delaying it to later in the day to get it up here for you.

Additionally, I’ll also be doing a bonus post Thursday with information from that day’s keynote! So you’ll have to wait a bit, but you’ll be getting twice as much content this week!

Thank you all for your patience here. Don’t forget you can check out the Remote Summit yourself by signing up here:

Until then, this is Rodney, asking “Have you updated your JIRA Issues today?”

Its all about them schemes

Last week we took a look at cleaning up your fields to help improve your system performance. So now we move on to our next Atlassian TAM suggested topic: How to standardize workflows and screens. But before we dive in…

Last week was amazing. I had a lot of engagement on this topic, and even had two more people come forward with requests for more topics to write about. I’m always up to do a reader suggested topic, so if you have something you want to see covered, let me know! It may be a few weeks before I can write on your topic (For once, it’s nice to have a backlog!), but I’ll definitely get to it. You can use the contact form on the blog’s website, or email me directly at

Anyways, lets get into it.

So, let me ask: Why would you want to standardize?

Fair question. This is going to be a lot of work, negotiation, and may come down to you telling them this is how it’s going to be. Why bother?

What’s the benefit that will make all this worthwhile? Well, the first benefit it helps teams within your organization work better together. If a person has to move from Team A to Team 1, they don’t have to relearn how to use JIRA. They’ll see the same fields and the same workflows. They’ll know how to use the tool as they’ve always have and be able to focus on getting to work that much quicker.

Secondly, It will help with reporting. With all the teams using the same workflows and fields, we have a consistent set of data across all teams with which to run reports and measure performance. While you should NEVER compare teams’ velocities to each other (as each team will value story points differently, therefore you will never get an oranges-to-oranges comparison), you can measure most other things consistently across the teams if they are all working from the same field set.

And the third, and I’d argue the most important reason to consider standardizing your schemes is your sanity. Look, there is only so much JIRA Admin to go around. If you are lucky, your organization has two or three of them to help out – but that’s usually for the largest organizations. Most small and medium businesses, it’s on you. Having standardize schemes stops you from having to play “What impact will this change have?”. You’ll know, and be able to get on with it that much faster.

But what about the exceptions?

Look. There will always be exceptions. A process or team that doesn’t adhere to normal business models. My Approvals workflow is such an example. But it’s your job to make it just that: An Exception. If you standardize your workflow, any change that is proposed by a team using the standard schemes should be measured on “How will this benefit the entire group?”. If it’s a benefit, it should be applied to the entire scheme. No breaking off a scheme to apply to a specific team. It’s all or none.

This, in and off itself, can help limit JIRA bloat. If a team has to defend why their change will benefit everyone, not just themselves, they will sometimes decide it’s not worth it.

So, where do I get started?

Honestly, I’d start with the screen schemes. And the first step is to talk with each and every one of your teams. Figure out what fields each one is using, and how they are using them. This will be time consuming – just a fair warning. But to do this successfully requires you to put in the work and really get to know your teams and how they work within JIRA.

Once you have that, sit down and compare your notes from all the teams. (You did take notes, right?) Find similarities, and try to get down to the fields you can get away with to allow as many teams to work as they already do as possible. Try to avoid fields that are used by only one team – opting instead to put that information in another field if possible, or the description. Take this time to use your test instance to make the changes. This will be both your testing and give you a way to demonstrate the change in a real way in our next step.

Now that you have your proposed standardized fields, this next step is probably the most important. Go back to each team, and present the new scheme proposal to them.

No, Seriously. Review what changes will impact their team specifically, and explain why you are making each change. Get feedback. Listen. Negotiate. Being willing to work with each team on this process is how you build buy-in, and it’s how you will make this process a success. Not everyone will be a 100% happy, and you may have to add some fields back in, but you can get them to a point where they can at least agree to the change. Again, I know this will take time, but having gone through this process myself, it is absolutely required.

So, you have con-census and buy in from your teams, and you have the changes ready to go in your test instance. You are now ready to push this to production..which in vanilla JIRA isn’t going to be fun. Without any plugins, you will need to manually recreate the new schemes in your production JIRA Instance, then assign all the appropriate projects to it. Or – you can use a tool like Botron’s Configuration Manager to copy over the new config as it exists from your test to production. Either way, I usually schedule a full change window for this during a relative down period for the instance (which invariably ends up being Saturday). No need having people try to work around you as you make these changes.

And that’s your Screen schemes standardized! When you are meeting with the teams, they may not understand why you are doing this. Stick with it – they will see the benefits eventually, and wonder why it wasn’t always like that.

But…uh…what about workflows?

Are you Forgetting something? Maybe you are,
Maybe you aren't - Are you Forgetting something? Maybe you are,
Maybe you aren't  Scumbag Brain

Yeah…workflows. I hadn’t forgotten about it – I was strategically putting it off. I promise!

My experience has been standardizing workflows is a bigger fight than screen schemes, which is why I chose to lead with that. People are willing to be flexible on fields – most people don’t use most custom fields anyways. But when you start messing with their workflows, you are messing with how they work. And yeah – that is part your job – but it’s going to be a fight. So start out with the screen schemes and build up some good will. That will make this easier.

With the Workflow schemes at least, you have the information at hand for each team. Teams are somewhat free-form in how they use fields, so you have to interview them first. But a workflow can only be used as designed. So start by looking at all the workflows for the projects you wish to standardize. Figure out the common points, and design a workflow (in your test instance!) that matches as many of them as possible.

Now that you have something designed, take it to those same teams. Explain to them what you hope to achieve, and demonstrate how the standard workflow you are proposing differs from the one that particular team is currently using. Go through the same thing with each team you did with the fields. Explain the benefits of everyone working on the same scheme. The object here is to build con-census from the ground up.

Look, I’m not going to sugarcoat it. People are going to disagree with you. Some are even going to do so passionately. Don’t make enemies of these people. If they care about how JIRA is being used THAT much, they are a person to have on your side. Figure out what their objections are, and figure out a way to address or otherwise work-around those objections. But show you are willing to work with their concerns, and they will be more willing to work with you.

Once you have all the concerns addressed and con-census built, schedule a change window and put it in place. You can do it manually, or by a plugin. Honestly, I keep harping on the plugin as an option as it eliminates some possibilities of you making a mistake. But if you are going to do it manually, at least export the workflow and re-import it into production, so you don’t have to worry about a mistake there.

And that’s it!

Look, this won’t be the easiest thing to do as a JIRA admin. People can be very passionate about how they work, and if you are seen as messing with that, they can get upset. But remember that they are upset because they do care, so if you can show that you are willing to listen and work with them, it should help.

So I know everything else in the world has been going a little crazy right now. I really hope you all survived the transition and ramping up your teams to work remotely. I’ve been stuck at home anyways while I recover from the surgery, but even before that I’ve been a remote employee for some time, so it still business as normal for me. I can write a post on tips and tricks from working from home, but it’s all likely advice you’ve heard elsewhere already, so unless requested I don’t have a plan to write on that topic. But if you are interested, let me know!

Don’t forget you can subscribe to receive new posts from this blog via email! To subscribe, just put your email in the form below this post! We also have an officially Unofficial Atlassian Discord chat. Swing in, ask questions, and see what’s going on!

But until next time, this is Rodney, asking “Have you updated your JIRA issues today?”

Spring Cleaning for Custom Fields

Well, I’m back…or at least upright. Thank you all for the well wishes I’ve received. As much as I hate not posting an actual article, I really did need the week off to recover. But now it’s time to get back to it. As I’ve stated, this week’s article was going to be a reader selected topic. It seems there was some demand for each, but the clear winner was…

I’ll be tackling the other articles in the coming weeks, but lets look at Getting those custom fields under control this week.

A bit of a confession here.

First, let me say that as Admins, I think each one of us has various strengths and weaknesses. Me, for example. My obvious strength is Systems. I can tune almost any system to run smoothly. I can learn new back-end technologies with almost no lead-time and still successfully deploy.

However, my weakness as a JIRA Admin is I’ve never been able to execute a successful Cleanup. I’ve known the problem, and I’ve worked to fix it. But I’d rather be a con-census builder than a dictator when it comes to JIRA, and people LOVE their custom fields.

To manage this, I’ve always put safeguards to keep things getting worse. I re-use fields rather than create new ones, and really analyze whether new fields are needed. But on systems I’ve taken over, it’s rare I get a group to give up a field that was already existing.

That being said, if you want to learn from a real master of this topic, I’d highly recommend Rachel Wright’s JIRA Strategy Admin Workbook.

However, I’m going to give you tools to analyze the problem, see what fields aren’t being used, and give you the data to say to people “This…this is a problem we can fix.” Then I’ll show you how to go about cleaning things up. So, lets learn together!

Why does this even matter?

So, you might be asking yourself “JIRA is all about the custom fields, why should I worry about how many there are?” That, honestly, is a fair question. But the reason you should care is performance. It’s just a fact: The more custom fields your system has to parse through, the slower things like creating an issue, searching, etc will be.

Average response times per action (in milliseconds): custom fields test. Courtesy Atlassian.

Take a look at this chart above. This is from some testing Atlassian did. If we look at JQL Searching alone, at 1400 custom fields, the performance is abysmal at almost 3 seconds. However, doubling the custom field count to 2800 triples that number to nearly 9 seconds.

And yes, this is an extreme case. But users will notice a delay of half a second. You will get comments saying JIRA is slow even at that number, trust me. And it doesn’t take too terribly many custom fields to get searching to be that slow. That is why your custom field count matters.


It is said the first step to fixing a problem is admitting you have a problem. Check. The second step it would seem is to figure out how big the problem is. Unfortunately, for this part we are going to have to go directly to the database.

For all my databases, I like to keep an administrative read-only account that will allow me to go in and query from time to time. This helps with making sure things are running properly, or diagnosing problems every now and again. Just make sure it’s read only so you don’t mess with something that aught not to be messed with.

Anyways, Atlassian has some queries that will help you figure out what fields are being used in your system. You can find all of them available here:

All the queries below I have confirmed are still working for MySQL 5.7 and JIRA 8.5.3.

Unused custom fields

select count(*),, customfield.cfname, customfield.description
from customfield left join customfieldvalue on = customfieldvalue.customfield
where customfieldvalue.stringvalue is null 
and customfieldvalue.numbervalue is null 
and customfieldvalue.textvalue is null
and customfieldvalue.datevalue is null
and customfield.CUSTOMFIELDTYPEKEY not like '%com.atlassian.servicedesk%'
and customfield.CUSTOMFIELDTYPEKEY not like '%com.pyxis.greenhopper%'
and customfield.CUSTOMFIELDTYPEKEY not like '%com.atlassian.bonfire%'
and customfield.CUSTOMFIELDTYPEKEY not like '%com.atlassian.jpo%'
group by, customfield.cfname, customfield.description;

So, the first logical question is to ask is what fields are just not being used – period. These can probably be thrown out easily enough. Just a word of caution with this query: It can return fields that are being used by Apps using their own datastore. I’ve modified it to at least throw out results from JIRA Service Desk, JIRA Software, Capture, and Portfolio So make sure you are vetting this list for such false postitives. But if it’s a field you or your team has created, and it’s on this list, it might be time to have a discussion on whether it needs to be around.

Custom fields that have not been updated after date (YYYY-MM-DD)

select, field.cfname from customfield field where field.cfname not in (
select item.field from changeitem item
JOIN changegroup cgroup ON
where item.fieldtype='custom' and cgroup.created > 'YYYY-MM-DD'
) and customfieldtypekey not like '%com.pyxis.greenhopper%'
and customfieldtypekey not like '%com.atlassian.servicedesk%'
and customfieldtypekey not like '%com.atlassian.bonfire%'
and customfieldtypekey not like '%com.atlassian.jpo%'

So this one returns fields that haven’t been used after a date. You’ll have to modify the query by replaying “YYYY-MM-DD” with a date you are interested in, but this one is handy for an end of year review, as it can answer “What fields have we not used this year”. If your teams haven’t touched the field in that long, you have a strong case for it’s need to go away.

Custom fields with low usage

select count(*),, customfield.cfname, customfield.description
from customfield left join customfieldvalue on = customfieldvalue.customfield
where customfield.CUSTOMFIELDTYPEKEY not like '%com.atlassian.servicedesk%'
and customfield.CUSTOMFIELDTYPEKEY not like '%com.pyxis.greenhopper%'
and customfield.CUSTOMFIELDTYPEKEY not like '%com.atlassian.bonfire%'
and customfield.CUSTOMFIELDTYPEKEY not like '%com.atlassian.jpo%'
and customfieldvalue.ID is not NULL
group by having count(*) < 5
order by count(*) desc

Unlike the first query, this one will return fields that do not meet a certain threshold of usage. As written, this threshold is 5 issues, but you can adjust it by changing the number in “count(*) < 5”. As a rule, I like to keep this to one-tenth of one percent of the total number of issues in your instance.. So if you have 400,000 issues in your instance, the threshold would be 400. But that is a personal preference, you should set this wherever it makes sense for you.

So, what now?

You know have your information, and you know what fields are not being used. You can just go and delete them, right?


Not really. You should do some more digging. Who asked for that field to be added? What was their business case? Was that field just recently added? For those with a small usage, are they only being used in a specific project? If so, what is the usage within that project?

Also, use Botron Power Admin to see where all the field is being used (or not used). This might tell you who you need to talk to as well.

This should help you narrow down your candidates further. Once you do that, go back to whoever requested those fields. Take the data from your queries, and let them know that the fields aren’t being used, and are on a list to be removed. You can also include documents on how custom fields impact performance for everyone. If you are lucky, they’ll agree with the data and you can remove it. If not, start negotiating. See why they think they need a field they aren’t using. See if there is a way you can give them their ask without the field.

Custom Field optimizer (Data Center)

For those of you on Data Center, JIRA has a built-in Custom field optimizer you can use. It will go through and find fields that are not used often, or otherwise “misconfigured” (As defined by Atlassian).

As you can see, it’s alerting on a field in my instance that has a global context. This was one I specifically created to test the optimizer, so it’s Ideally, you should limit your custom fields to only be available to the projects that need it. So you can use this tool to find those with global contexts and if necessary, fix them.

Merging Fields (App Required)

So, lets say you have a duplicate field. How do you copy the information from one to another so you can delete one without losing data?

Well, as you can guess, this isn’t something that is able to be done in vanilla JIRA – so we have to turn to the Atlassian Marketplace – and specifically Adaptavist’s Scriptrunner plugin.

Now my groovy – it needs some work. But Scriptrunner has a number of built in scripts, including one to “Copy custom field values”. This does what it says on the tin. It takes the value in a source field, and places it into a destination field, overwriting what was there. For most cases, this won’t be a problem for reasons I’ll talk about later, but do keep this in mind.

To use this, you will first need to save a filter that will limit what issues it will copy the fields on. I use something along the lines of:

"Custom Field A" is not EMPTY

This will return all issues that has the custom field set. You can add another clause to weed out those that have the destination field already set, and handle combining those manually. In most cases, each of the duplicate fields would have only been used on a project or two a piece, and have no overlap, so this shouldn’t be too much of a concern, but as always do your research first and make sure that is not the case in your situation.

Now, I shouldn’t have to say this, but always test any changes you want to make before doing it in production. That’s very true here. This built-in script isn’t perfect, and you may have to pick it apart and modify it a bit to get to your use case. The only way to know if this is required is to do your testing.

That being said, I asked my colleagues at Coyote Creek about merging fields, and Neil Taylor gave me this as a solutions he’s used before. From testing it, it’s the easiest to implement and execute that I’ve found, and should handle most of your use cases.

So time to get cleaning!

So you know how to find fields that are good candidates to removal, and have an action plan to migrate the data should they have anything worth keeping in them. What are you waiting for? Get out there, start conversations, and get yourself on a better path to better JIRA Performance.

Don’t forget to subscribe to receive new posts by email. It’s the easiest way to be notified as soon as the posts go live. You can sign up with the form at the bottom of the post. And don’t forget to check out our Atlassian Discord Chat!It’s always interesting to see who has popped up there and what’s being discussed.

But until next time, this is Rodney, asking “Have you updated your JIRA issues today?”

What happens when you are busy making other plans…

So this week has been an interesting one. Today’s post will be short. I know I promised you an article this week based on how you guys voted in last week’s poll, but you see…

Something came up.

After I got done with last week’s article, I went to have some testing done to find the root cause to some health problems I’ve been having. And well, we found the problem. It was bad enough that the doctor had me go to the ER.

What she found was a very large amount of fluid around my heart. As a result, I’ve unfortunately spent six days in the hospital. Because of where this fluid was, they couldn’t remove it the normal way, so I had to have surgery last Thursday, where they removed 600ml from around my heart! I don’t recommend that as recreational activity. So not fun…

It’s been almost a week now since the surgery, and I am recovering nicely. I cannot describe what it’s like to have that much fluid removed at once, but it was a definite difference I can feel. I’ve had a busy week trying to build back my strength and recover.

Which means, as much as I don’t want to disappoint you guys, I do need to be honest with you and say that I wasn’t able do a full article this week. I’m really am sorry – I was looking forward to this article too. But priorities are priorities.

I have opted to keep the poll open for another week though, so if you didn’t vote last week, you still have a chance!

However, some other news this week.

Look, at the point I was in the hospital, I had pretty much ruled out Summit this year. No way my doctors would let me travel so soon.

But that’s okay. Due to concerns about COVID-19, Atlassian has decided to cancel the in-person Summit this year and take it virtual instead.

While I had some surprises planned if I could attend, I cannot fault Atlassian for it’s overabundance of caution. To sign up for the now free virtual event, follow the link below.

So, this week appears to be the week of the unexpected. I do apologize for not having this week’s article ready, but one of my resolutions was to take care of myself, so here we are. Until next time, this is Rodney, asking “Have you updated your Jira Issues today?”

The JIRA Guy’s Summit 2020 Preview

So, Atlassian’s annual conference in the US, “Summit”, is now less than 30 days away. And at the time of writing I don’t know if I’ll be going to Summit yet. I would very much like to, but there are some final logistical hurdles to overcome first. But, I wanted to take a look ahead to it and figure out what breakout sessions I’d recommend to you, and which I’ll be going to if I can.

Now my advice is if you can, DEFINITELY go to Summit. It is an amazing learning experience each time I have gone. But much like me, it may not be possible for everyone to go every year. As I’ve stated previously, Atlassian has been very good about posting breakout sessions and keynotes to their YouTube page. I very much intend this to be running in the background while I work if I can’t go – and I’ll definitely be focusing in on the sessions I point out here today. But if I can go, I have some special plans for you readers from this blog.

So lets get into this

How Atlassian Enterprise Services are Unleashing our potential

Speaker: Christopher Heritage, Agile Leader, NextEra Energy
Time: 02 April, 2020 @ 3:00 PM
Room: Oceanside F

So this one seems like it will be a good story on how Atlassian’s Enterprise Services – that is to say their Premier Support and Technical Account Mangers (TAM’s) helped NextEra Energy scale and grow their Atlassian deployment. I’ve also had a really good experience with the Enterprise Services people (Hi guys!), and know more than a few of them personally, so I’ll be going here for more stories I can pass on to clients who are on the fence about signing up. If you are thinking “Are Atlassian Enterprise Services for me?”, maybe check out this session to hear first hand what they can do for you.

How to clean up your Atlassian suite (without losing your damn mind)

Speaker: Alex Christensen, Lead Atlassian Suite Engineer, AppDynamics
Time: 01 April, 2020 @ 3:05 PM
Room: Oceanside D

So, you get onto a new job, just to realize the JIRA Instance is a complete mess. This is a topic I am actually planning on touching here soon. I’ve had several experiences with messy JIRA Instances, and seen many more.

So, what do you do? Alex will guide us on how they went about cleaning several “messy” instances, and best practices they do to keep it clean.

How we learned to stop worrying and love weekday upgrades

Speaker: Ed Bukoski, Software Engineer, Netflix
Time: 02 April, 2020 @ 11:00 AM
Room: Oceanside C

Okay, going to admit, the title of this one gave me a mild panic attack.

Downtime is a necessary evil, and in the days when JIRA Server was the only deployment option, it was required for an uptime. But as a point of pride, I’d prefer my systems be up when people need them – which meant I’ve done A LOT of weekend upgrades.

However, with the Data Center Deployment option, you don’t have to bring the system down to upgrade it. This does open up the ability to do an upgrade during the weekday – without the system being down for your users. This is exactly what Ed intends to talk about, and the consequences there-in. Should be an interesting talk.

How to Un-F*** Jira

Speaker: Jon Kern, Agile Consultant, Adaptavist
Time: 31 March, 2020, 1:55 PM
Room: Oceanside C

Jon here speaks to something I’ve seen to often. Agile is meant about making things simple. So why do so many organizations make their JIRA usage so complicated? This is the curse with any highly configurable tool: People will see everything they can do, and feel they need to use it all. Jon will present several best practices for administering JIRA while honoring agile principles.

Personal branding for people who hate personal branding

Speaker: Megha Narayan, Head of Brand, Atlassian
Time: 02 April, 2020, 4:25 PM
Room: Mandalay Bay J

So, something I had to come to terms with during my job hunt is that I have a brand, and I haven’t been managing it to that point. This blog has made that even clearer. Megha will be speaking to just that – how defining your brand can be a very good thing for you and your teams. She also share tips from brands like Apple and Nike that you can apply to your personal brand. Sounds like a must-listen to me

Dev Teams & Dragons: From DM to PM

Speaker: Anthony Nomorosa, UX Designer, Atlassian
Time: 01 April, 2020, 11:00 AM
Room: Oceanside F

So, what does Dungeons & Dragons, the classic yet resurgent table top RPG have to do with leading a team?

A lot actually! Anthony will share how he takes lessons learned from the game and use it to foster communication, motivation, and empathy within cross-functional teams. As I’ve recently gotten back into playing myself after some 20 years, this one is a can’t miss for me.

Will you be at summit?

As I said, I will be there if I can make it. Will you be there? I hope so!

So, for the next blog post, I’m going to be doing something different. I was recently contacted by a friend of mine that works as an Atlassian TAM. Atlassians are reading my Atlassian blog – that blew my mind. But he also had several requests of topics that we can cover – and honestly, they are all too good, I can’t decide! So instead, I’ll let you decide.

I’ll let this run to Noon EDT on Sunday, 8 March, 2020 – at which point I’ll have to start writing whatever you chose to talk about!

In speaking of the blog, we hit a new high monthly viewership in February with 550 page views! I thought it would be a while before we beat last January, as it was a rare month with five posts published, but we did it in a month with only four! Lets see what March will bring.

If the numbers are to be believed, LinkedIn hasn’t been sharing the articles the past two weeks as widely as they previously had – or our numbers would have been even larger! If you want to help me change that, start a conversation within the comments of the LinkedIn Post! That is one of the key parameters their algorithm looks at when deciding to show it to new people. Thank you!

Don’t forget to subscribe to get our new blog posts directly to your email! The Email Subscription form will be at the bottom of this post. Also don’t forget to check out our Atlassian Discord Chat!It’s always interesting to see who has popped up there and what’s being discussed.

But until next time, this is Rodney, asking “Have you updated your JIRA issues today?”