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

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Top 3 Instance Configuration Actions for Novice Jira Admin Edited

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.


Log in or Sign up to comment
Community showcase
Published in Agile

On-demand: Fireside chat with Atlassian on scaling agile organizations

Scaling an agile organization and setting it up for success over the long term is a hard thing to do. We hear a common set of questions from customers all the time, questions like: Can agile scal...

3,847 views 1 15
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you