You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Hi! I'd love to hear from other Admins re. Jira standards (for example: naming conventions, user permissions best practices, data consistency, etc. …) that you have found to be particularly helpful:
Thank you so much in advance for your responses! They are greatly appreciated!
I would also add that if you are not the lone Jira admin to make sure you and the other admins have a nice standard operating procedure regarding user requests so that you are all on the same page and don't make poor or less manageable decisions just to make that one user happy. It's ok to have a quick chat with each other about long term implications and push back on requests by offering alternate solutions that will make your job much easier.
I guess you were hit by a team managed project when you were young and you still remember it.
I use them intensively for non-it teams like HRs, Reception, etc. It removed tones of workload for me - just show team member how to manage them and voila - they do what they want and do not bother you.
I was definitely bit by one as a child Sergei Gridnevskii ;)
I am surprised to hear your users don't bother you though. It seems like every day someone reaches out to me to ask how they can fix\adjust\do something only for me to find out "oh that's very basic feature is not a thing in TMP's".
Another very useful tip.
Create a project that would solely serve changes in Jira itself. For every config change requested by users create a Jira issue. Whenever possible describe the change with issue key. E.g. if you edit a workflow mark it with [ISSUE-223] in change description.
It helps a lot to find who made a change and why.
I've found giving each project their own specific config - schemes, workflows, screens etc to be much easier.
On the surface it seems like more work, but it really isn't!
Even if i am copying a scheme, i rename to specific project - this allows me much more freedom when it comes to customising the project to suit their needs and not having to worry about the impact that could have on other projects if sharing the same config. We have some projects using the shared config and I personally find it a nightmare to manage changes.
Yes, same for me. If you forget/don't notice that a config is shared a minute after you make a change you have an angry team member from another team asking you to roll back changes.
For me a rule of a thumb is to make a copy and make changes in a copy. Unless all teams agree that they need this change.
P.S. One of the strangest "features" in Jira is that when you change a status in one workflow it is changed automatically in all other workflows without any warnings. E.g. if you rename Done to Complete all projects will have Complete status.
I like this method too - often new projects need bespoke/ new fields for different reporting outputs etc, so this enables changes to fields and what not without impacting the other projects.
But I have a couple project templates that are kept up to date and reviewed with the project managers, kind of acts like a master config which saves time!
Recommended Learning For You
Level up your skills with Atlassian learning
Configure Jira Software, Jira Core, or Jira Service Management, including global settings, permissions, and schemes.
Managing Jira Projects Cloud
Learn to create and configure company-managed projects in Jira Software and partner effectively with Jira Admins.
Managing Permissions in Jira Cloud
Sharpen your skills at configuring and troubleshooting permissions in Jira Cloud with this free course.