What small Jira admin habits save you the most time?

[Maya Lindholm]

I have been keeping notes from a small Jira and Confluence sandbox, and I am curious what habits other admins find most useful.

For me, the biggest time savers are:

- naming automation rules clearly

- keeping workflow changes small

- testing permission changes with a non-admin user

- documenting why a field or status exists

What is one habit that has saved you time or confusion later?

[Akina Dudde]

Things that have already saved me a lot of time:

• Documenting what I did and why
• Creating a ticket even for minor adjustments
• Writing descriptions of automation rules of what they do
• Writing instructions for tasks that aren't performed frequently
• Writing scripts for recurring tasks

[s_gridnevskii]

It is very easy to document changes if you have a separate project for change requests. Then you just add key of change to description of a workflow or screen scheme of an item and you can track who asked for change and why.

[Ignacio Pulgar]

#1 - Automate license provisioning/deprovisioning

This is arguably the best time-saver ever.

Users should have a portal from which they can get or regain access to Jira/Confluence with no admin action.

An automated solution should be in place to remove licenses from users based on the last time they used each app.

#2 - Solution for space access management

Implement a way in which end users could effectively direct their space access requests to the space admins with no app admin action.

There are some native request access buttons in Jira and Confluence that may help under some circumstances.

But sometimes users know the space they would need access to while lacking a explicit URL, which is needed for the native buttons to help.

#3 - You can do it = You must do it

If anything can be done by end users, it must be done by end users, not by Jira admins.

If they don't know how to do it, we will help them, ideally by providing them with a link to a Confluence page or Loom video showing how to do it.

If they lacked permissions to do so, they should either be provided with permissions or be directed to someone else who had the necessary permissions.

This also means Jira admins should never update work items on behalf of end users.

Editing tickets on behalf of end users is also an error because of the fact someone will eventually ask you about the reason why you modified something in a given work item, as the history tab will always store this fact.

You will end up having to research where a user requested you to do that... since you won't remember why in a few months.

[Viktoriya Kazunka]

Hi! 
Could you please provide more details regarding the first automation? In our company, new hire requests are created by HR specialists via the Portal, and then they come to me as the Atlassian administrator. After that, I manually grant the accesses. It would be great to automate this, but as far as I know, it is not possible out of the box in Atlassian. Do you implement this via API or, for example, in combination with Active Directory?

[Haddon Fisher]

It's been a minute since I did this, but the pattern is I believe to have your directory map users into a group which automatically grants Atlassian seats to members.

One word of caution - I have had plenty of fun detangling permissions from licencing, so if you are just starting out, I would try to avoid granting access to specific content using the same groups you are using to provide your licencing.

[Urmo]

Hi

Writting things into tickets and write documentation to end users is must be. Yes, claude, rovo, chatgpt, gemini etc is very good things but users like to know how things was set up.

Jira ticket is needed because its only way when user ask why i did so or i need to remeber by myself that why i did so.

Lot of automations are needed to get more time to build new things.

[s_gridnevskii]

Bookmarks to most importand settings in browser. 

I also configured shortcuts P: project name and I: issue key for search string in browser.

[Sean]

Can you elaborate on the shortcuts, the new UI is forcing us to look at other ways to quicky navigate issues/projects

[s_gridnevskii]

You go to chrome://settings/searchEngines in Chrome, then click Manage search engines and site search, then scroll down to site search and click Add

I have the following for Jira

Name: Jira
Shortcut: j
URL: https://myjira/issues/?jql=key=%s

When I press j and tab in search string I type issue number and get into Jira search with issue selected. If you replace URL with

https://myjira/issues/?jql=text~"%s"

it will search for text.

[Suresh]

@s_gridnevskii What about Project search URL

[s_gridnevskii]

@Suresh in fact all you need is to put %s into the URL you need to open instead of project key. E.g. if you want to open Users and Roles section in on-prem use this URL

https://yourjira/plugins/servlet/project-config/%s/roles

[Suresh]

@s_gridnevskii : looks like it is works for roles and not project as in 

https://myjira/plugins/servlet/project-config/%s/ or 

https://myjira/plugins/servlet/project-config/%s/summary.

It is always lowering the case and erroring out as Atlassian is looking for Upper case.

[Suresh]

Rovo gave this suggestion

javascript:void(window.location='https://myjira/plugins/servlet/project-config/'+prompt('Project Key:').toUpperCase()+'/summary')

and it worked. It just prompts a window to enter the key 2-steps instead of 1.

[Haddon Fisher]

I wrote some instructions for users on this a while back if it helps.

I had one for project search but Atlassian recently broke the URL pattern by adding in what "flavor" of Jira the project is, so there isn't a consistent path for all projects anymore.

[Anne Saunders]

There's already a ton of good advice in this thread, so I'll add for fields, statuses, transitions, and other things that have a description field available, use the description field!

The advice I give my team is to be economical; sometimes as few s 3 words is enough! The secret is that you need enough words so that a teammate can understand, or at least enough so that 6 months from now, you can understand why / how you did what you did.

[Kristin Lyons]

Keeping everything consistent - IE same naming convention for everything!

[Haddon Fisher]

- Disable "team managed project" creation.

- Naming conventions for everything.

- Create a Confluence space to hold documentation about how your org uses Jira.

- Create a Jira space for your org to use to track & manage Jira requests.

2026 was actually a bit of a game-changer as far as Jira admin for me:

- VIBE CODE YOUR OWN JIRA ADMIN LAYER

I've literally never been happier administering now that I don't have to touch most of the Jira surfaces to do it.

[Lisa Colbatzky]

Can you please explain your set up of the vibe coded app? :-) 

[Haddon Fisher]

I'm using Codex for as much Jira administration as I can throw at it these days; I have found a lot of success in a couple of specific areas:

1. Vibe-Coded SPA's

I can document it a little more thoroughly if the sleeping pills aren't working for you anymore, but TL;DR: our quarterly planning process involves a semi-intricate set of custom fields and field values which must be consistent across our 39 development teams, plus a set of automation rules to plumb it all together. Maintaining this used to be a tremendous lift - just moving from one set of pick-list values to another took me several days of planned effort - and since a lot of the Automation rules involve string-manipulation, even a misplaced space can create very hard-to-troubleshoot bugs.

I fed Codex our roadmap item tickets (calling out the custom fields I was interested in), the documentation around our quarterly planning process, and then used `grill-me` and "plan mode" to confirm it had a good understanding of all of the data requirements we had. Then I said "build me a web interface I can use to validate all of these rules". Once I had this in place, I expanded functionality to include CRUD activity and other criteria. 

2. The other way I've used this is to perform targeted maintenance which would be extremely time-consuming manually. For example, we are rolling out a new agentic development system which is baked partially into Jira workflows - I have used Codex to create workflow and workflow issuetype schemes and then help me plan and carry out the migration of projects from old to new schemes.

Some learnings:

- I uninstalled Rovo and pretty much exclusively use the Jira API for everything. I found that it would often route things to Rovo assuming that "all Jira things go through Rovo" only to find out that Rovo couldn't actually do what I wanted. The API on the other hand can do pretty much anything that can be done.

- I don't spend a lot of time writing long and intricate prompts upfront anymore. I will still spend a lot of time in "plan" mode and\or using `grill-me`, but I have found it is often quicker to simply ask Codex to look at my Jira tickets, homegrown documentation and process pages and say "figure it out and explain it to me so I can correct where you're wrong."

- I ended up setting up a PKSE authentication app so that I could do less-bad authentication and share these applications with my peers. It was easier and safer than using API tokens and hiding from my CorpSec team, and was surprisingly easy to do. Now my users can load these applications, authenticate to Jira using our Okta SSO, and whatever they do in my applications (and flows into Jira) has the correct attribution.

[Susan Waldrip]

Great vibe coding ideas, @Haddon Fisher. Thanks for sharing all this.

[Becker_ Rene]

Adding the Custom Field ID at the end of each field description.

Example:

This field is here to be used for good and not evil but only input numbers that are above 50. [12345]

This allows me and API devs to quickly identify the field ID. Since using Field names to search for content (esp. with API) is a big No-No, this has saved a lot of time and trouble/debugging (which again saves time).

Cheers :-) 

---

[Jewell Sutton]

Thanks Maya for sharing! I created a "Jira Playbook" (given it was a new platform for our marketing dept and is now used for onboarding new employees) and establishing expectations by role.  Huge was Priority Setting - defining them with examples and factors that drive it.

If anyone has "summary" naming convention guidelines they'd be willing to share, that would be lovely. 

Best,

Jewell Sutton

[Susan Waldrip]

Hi @Maya Lindholm , Welcome to the Community! This is a great discussion, I've already learned a lot so thank you. Not sure if this is your case, but most of our projects/spaces are team-based so we use shared schemes (e.g., Permissions) and Notifications setups wherever possible. If a new space is going to be a lot like an existing space, I'll create the new space with the "Share settings with an existing space" feature selected and then (if needed) copy any schemes, etc. that need to be unique for the new space and name them accordingly. These methods may seem obvious, but I've seen a lot of (new) folks in the Community asking for help with setting up a new space like their similar existing spaces and these practices have saved a ton of time.