4 top tips for Atlassian admins keen to control large instances

On one side, each team, and sometimes even individual users, have specific needs and requests for their Atlassian tools usage 

On the other, all these teams and individual users need a structured way of working together to function efficiently 

Here’s a few tricks we’re using at PAYBACK to keep the balance between structure and flexibility. 

To give a bit of context, with over 31 million active users, PAYBACK is Germany's leading customer loyalty and multichannel marketing platform. To support the worldwide growth, the company leverages a large on-premise Atlassian stack, which includes Jira, Confluence, Bitbucket, Crucible, Fisheye, Crowd, and Jira Service Desk. The entire stack is administered and serviced by the Collaboration Management team - which includes myself and two other colleagues working part-time. 

Atlassian tools provide great opportunities for building your applications exactly as you need them. But, the same freedom can cause huge complexity when it comes to permission control, especially in a fast growing instance. This is exactly the challenge we faced initially. 

As our instances got bigger and bigger, we saw more and more situations where we had many groups of users working on the same project with no clarity as to why one user was able to do something in their application while another one was not. 

Our solution was to drastically simplify everything! 

Excluding critical actions (such as deleting issues), permissions in Jira, Confluence or Bitbucket can be scoped down to three basic levels: Administration, Read-Write, Read. 

In Jira we created one generic permission scheme based on the three roles and established our project-based groups to fit these roles. With a 1:1 relation on this level, we reduced the complexity for our Jira application. Combined with an IAM Application we’ve built on Oracle APEX, users are now able to grant themselves permissions for these groups. Each permission-grant requires a management (direct management, team lead) approval. While some also require a group owner permission approval. We then applied the same scheme to Confluence, and Bitbucket. 

The next step was to identify expert-users - people with good working knowledge of the tools but also with a deep understanding of their projects and teams. Within PAYBACK, we call these experts context owners. 

We put the context owners in charge of answering approval requests and of requesting permissions for new colleagues onboarding their teams. 

This is not the only role of our context owners. They also gather the needs of their colleagues and centralise issues ranking and priority of features that should be implemented on our Atlassian tools and present them to the Collaboration Management team. 

With a smaller scope of potential requestors, my team can keep our users close without having to attend multiple meetings each day. Our stakeholders gather user requests, discuss and pre-sort them for us, we strategise and implement any changes according to the wider necessities of the business.

Before becoming the Automation & Collaboration manager at PAYBACK I was an external Atlassian consultant for many years, so I’ve seen and known in detail a great deal of Atlassian implementations. One thing I can tell you for certain is that the larger your instance, the more you will need automation and customisation to make it do what you need it to do in a reasonable amount of time. At PAYBACK, everything that can be automated to save time and human brain power is automated. 

Our preferred automation and customisation app is ScriptRunner. We are using ScriptRunner for Jira, ScriptRunner for Confluence, and ScriptRunner for Bitbucket, and we have created hundreds of automations and customisations using both built-in options and custom Groovy scripts. To give a few examples of what we achieved: 

Added custom fields on Jira issues to show the upper hierarchy level issues they are connected to. This saved our Project Managers approx 40 hours/week.

A bot that posts a message in the general channel of the company every time an announcement blog post is posted on the intranet - extended to specific announcements for various teams when a pull request is raised, etc. 

Auto-adding and checking for approvers on Pull Request in Bitbucket.

We love ScriptRunner because, thanks to Groovy scripting, it allows us to do pretty much anything with our Atlassian stack. However, our small Collaboration Management team simply does not have the capacity to create all the scripts required in a timely manner. But a lot of our expert-users are also excellent coders, so the next step will be to allow them to create the automation scripts they need, while the ultimate power to approve and deploy these scripts will remain with our team. 

Our puppetised master/dev/stg instances automatically get up-to-date ScriptRunner Script-Root versions, separated by branches of the same name. We hold one repository per application and centralise these repositories in an Atlassian-Project (not restricted to our own team but open for other teams to modify configurations as well). 

Some introduction lines tell the developer what the script will be used for and what is the Jira issue the code was requested with. This information provides the possibility of examining why the script has been written in the first place. And, with ad-hoc information and testing usually documented within these Jira issues, you can easily discover even more details about the implementation. 

While Confluence is a pretty good place for documentation, we hold just as much directly in / next to our code as possible. The scriptFragment i’ve written just yesterday wouldn’t be complete without a markdown-file holding information on how the scriptFragments has to be configured in the UI (name, key, weight…).

In my opinion, in order to be as flexible as possible with your user’s needs, you need to find ways to avoid micromanaging. The approach we take at PAYBACK helps my team achieve just that. We actually managed to turn the role of our team around: from being mostly reactive and responding to user requests as and when they come in, to being mostly proactive, constantly chasing up ways to improve our tools and processes. 

From one Admin to the other, I wish you Good Luck!