What would be your advice to first-time Jira admins?

[#1]

Hey admins!

We're bringing back a discussion prompt from 2018! In the last 7 years, there have been so many changes to Jira, and consequently, the admin experience.

For admins with experience, this is not only an opportunity to make the forum more accessible for newer admins, but also an opportunity to reflect on your journey.                                                                           

So what tips, tricks, and pitfalls do you wish you knew about when you first started out?

Let us know in the comments below!

[s_gridnevskii]

I think every Jira admin should start with installing staging Jira for various tests. It can be a cloud instance or a data center. It is much better to make changes first on test server and then on prod - it would save you a lot of nerves. Additionally if someone from your company wants to play around with Jira, e.g. create workflow or make some automation rules you can always give him admin access to test server and when copy settings to prod after you make sure they are safe.

[Leonel Goitia]

As someone managing complex integrations between Jira Assets and external systems like Azure AD, Intune, SCCM, and Meraki, my advice to new Jira admins is:

- Document everything from the start: whether it's custom field usage, automation rules, import mappings, or API tokens. Clear documentation in Confluence has saved me countless hours when troubleshooting or onboarding others.

- Understand the object schema before automating: Especially with Assets (formerly Insight), defining a solid object model and clear attribute relationships is critical. Poor planning here creates long-term technical debt.

- Test in isolation before scaling: Before automating imports or integrations, validate small payloads via the API. Don't assume a working script will scale without issues. Timeouts, attribute mismatches, or circular references are easy to miss.

- Use staging environments when possible: Even with Jira Cloud, use sandboxes or clone projects to test workflows, imports, and custom field configurations. Avoid experimenting in production.

- Leverage automation carefully: Automation rules are powerful, but without proper logging or scope control, they can create data loops or override key information. Use logging actions and limit triggers where appropriate.

Your job isn't just to make things work,  it's to make them sustainable, scalable, and supportable.

[Chris]

Well, where to start? Jira is a very cool toolbox that can be used to support any process you like.

Atlassian is very good at pushing new features, be prepared to see small and big changes every day - often without warning beforehand. Atlassian is very good at pushing new features that are not fully thought through. (Team field or email logs to mention two of many. Prepare to see a lot of feature requests that wait for years to leave the "gathering interest state".)

But still, Jira is a good toolbox. :-)

I would mention three things for new admins: naming conventions, custom fields and state names.
Be very tight on naming conventions for workflows, schemas, ... if you don't, you will have a mess and things get very complicated.
Don't do custom fields for everything. If you have a start date in one project, reuse it in others. Don't create new custom fields for the same thing.
Don't create a new state if not absolutely needed. Try to reuse them over projects.

I have used a lot of post functions ( -> JMWE App), but tend to do more Automations now.

[s_gridnevskii]

@Leonel Goitia yes you are right. All changes to Jira should be done through jira tasks. I have a special project for changes and whenever I change something I give an url and change identifier in change task.

E.g. if I change workflow I give it next version number, like this one:

Developers Workflow v.1.5

and add this text as a comment. Later when guys ask me why I change workflow I just search for the name an find the change task.

As for the automation - a beginner should pay attention to rules that may take some time or CPU, like modifying a couple of hundreds of issues. Sometimes it is better to make an additional custom field in the issue that would hold calculation results rather than calculating them again and again in a rule. 

Also admin should limit access rights to the lowest possible level for each employee. If company is big and employee has access to all projects of all departments Jira search may give him hundreds of results while he just needs dozens. Board filters should also include the only projects that are needed, then reports work much much faster.

[Filip Labarque]

- Start by creating a set of Jira project templates, create new Jira projects based on those project templates.

- Don't grant Jira admin permissions to end-users. Sadly this means the jira system admins will need to create new projects.

- Avoid team managed projects!

[s_gridnevskii]

@Filip Labarque also a good idea would be to explain team members that components work better than projects and it is better for all to create a component in existing project than creating a new project.

Also I would recommend to follow team structure in projects. E.g. if QA team is a separate unit and it tests bugs in several projects I would create a dedicated project for QA where they could have their own boards and sprints. This will insure they can work in parallel with developers and schedule their activities independently.

[Thorsten Letschert _Decadis AG_]

Ah, the beauty and the beast that is Jira’s flexibility! 😅

If I had to narrow it down to just two golden rules from my admin journey, they’d be:

• Just because you can customize doesn’t mean you should.
  Jira’s configurability is a superpower — but use it wisely. Every new custom field or workflow tweak might feel like a quick win, but over time, you might find yourself untangling a spaghetti monster of your own making. Think long-term!
• Learn to say “no” — or at least, “why?”
  Not every ad-hoc request needs to be granted. Teams often have tunnel vision for their project needs, but as an admin, you're the steward of the whole site (or even multiple sites within the org). Guard the forest, not just the trees. 🌲

There are tons more lessons, of course — but these two? Lifesavers.

P.S. Looking forward to more answers to come.

[Leonel Goitia]

@Thorsten Letschert _Decadis AG_ 

Absolutely agree with this! Jira’s flexibility is both its biggest strength and its biggest challenge. I’ve learned the hard way that adding “just one more” custom field or workflow tweak can snowball into a complex, hard-to-maintain setup.

And most importantly, Jira won’t fix broken processes. You need to optimize and streamline your processes first, and only then translate them into Jira. Otherwise, you just end up digitizing chaos. Saying “no” or asking “why” is crucial to keep the instance healthy and scalable. Couldn’t have said it better myself!

[bmccarthy]

Completely agree on Jira's flexibility...  biggest strength and biggest challenge!   

Be Very Careful on who you allow to be Jira Admins.  And, limit your Admins. 

We have way too many customizations that weren't necessary.  But, now a huge effort to unravel.    

[Matt Doar _Adaptavist_]

All good ideas in the other comments. I would add "find a mentor if possible" and discuss a few different approaches to customer requests. Join your local ACE and meet some other Atlassian administrators as well - you never know when you'll need a different job these days.