Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Top 3 Instance Configuration Actions for Novice Jira Admin


We have a novice Jira admin who needs to configure a new Jira Software instance for a Product Development Team.

Your thoughts: What are top three critical actions this admin should do in customizing this new instance in order to make this team successful in Jira Software, and why? 

("Actions" meaning updating settings or features like permissions, schemes, boards, roles, dashboards, workflows, etc.)


1. Think about and configure new groups And Group membership of users.
2. Think about and configure global Project Roles you need. (Don't forget the default members). Associate users&groups to Project Roles in each Project. 
3. Create Project "templates" with configuration schemes you can reuse when you create new projects ("with shared configuration"). One template per project "category". Configure notifications & permission schemes with Roles.
Like # people like this

Thank you @Mariano Galán Martín! Great feedback!

We allowed teams to customize their JIRA instance to meeting their teams needs since we had no direction from our leadership to standardize.  the result was a 2000 hour project and a lot of of pissed off users who had to change.  (at one point we had 52 JIRA Admins, it grew organically to 2000 users, today we have 3800 ) 

I strongly encourage the restriction or limitation of allowing teams to create their own custom fields, workflow statuses, and other system level configurations. 

we found that JIRA out of the box was more powerful to transform teams then complex processes and workflows they created.

We created very loose best practices that drove our we created project templates and what teams could do on their own.  

Most important:   Think of reporting first!   if we considered our reporting requirements up front, 90% of our decisions would have been different.

Like Dmitriy Garanzha likes this

+1 for Reporting first - this resonates strong with my experience in a totally different field - map making. For example, knowing when you start that international borders need to visually distinguished from internal border saves a lot of time fixing after the fact. To avoid spending all your time hand tuning every line the "border" features can to have a "type" field international lines are drawn differently from province different from state different from county different from municipal, all powered from a single symbol rule set. 

Noted, thank you for posting on this topic. Very important to keep in mind.

Try organizing your boards and teams in Process flow first. When I started at my current company there was a board for everything and it was an adminstrative nightmare to get it cleaned up. I agree with the above posts to limit the amount of Admin rights that you grant within your Org.

Reporting first is definitely important, especially if you're wanting to demonstrate value - it means you have a fixed baseline from the start, and can then use the reporting to measure how the system is affecting (and hopefully improving!) performance of the teams using it.

1) Board

2)Workflow and permissions

3) Filters

I agree a lot with its being said.

I'd like to add, that to me the first most important step is to talk with the Projects Administrators (and key users)  to know what problems are they facing into using jira to track and organize their projects and teams.

Then establish a set of priority objectives to change in order to solve those problems. Always having in mind the best practices in the configuration of jira, such configuring the needed groups, creating the project roles and standardizing schemes (permission, notifications, workflows) to be use in most project. In order to share as much schemes configuration's as possible, in this matter avoid overload of schemes (and therefore improve the administration work and performance)

My firsts to consider:

Roles: Discuss, Communicate & Configure Global Project Roles, Groups.

Permission: Now that you have an idea of the Roles who belongs in what group and what permissions will they require to execute their function(s). 

Project Type: Agile or Not - Considerations Frequency of Change, Incremental, "WestWorld" or "Waterfallish" all will determine what Project 'type' that will best fit the work ahead.

We allowed teams to customize their JIRA example to assembly their teams needs when you consider that we had no direction from our leadership to help. The end result changed into a 2000 hour task and a lot of of annoyed customers who had to change.

Thanks For posting. That is great and helpful  I will get the knowledge. 


Log in or Sign up to comment

Atlassian Community Events