How do you keep your Atlassian site running smoothly? What should be included in the Admin handbook

[#1]

I work a lot with regulatory-heavy organisations, and I’m always helping teams keep their sites ‘in a state of validation.’

But honestly, it doesn’t matter what industry you’re in—regulated or not—if thousands (or tens of thousands!) of people rely on your Atlassian site, you want it running like a well-oiled machine.

So instead of calling it a ‘state of validation,’ let’s talk about how to keep your Atlassian site truly Enterprise Ready—day in, day out.

Here are my tips:

1. Keep your admin team lean (but with some redundancy). Admins have significant power—they can make changes that ripple across the entire organization. So make sure every admin really knows their stuff.
2. Every admin should have at least a baseline understanding of how the platform works. These days, many organizations believe they can get by without any real administrative expertise—but that often leads to missed opportunities and unnecessary headaches. Even basic troubleshooting skills will help your admins answer questions, onboard new teammates faster, and make smart tweaks that save everyone time. If you don’t have admin knowledge in-house, you’re barely scratching the surface of what the platform can do.
3. Keep track of your Marketplace apps. Have a clear process for adding or removing them—even if it’s simple. Always test new apps in a sandbox before rolling them out on production.
4. Decide your permissions policy:
5. 1. Who gets access to the platform
   2. Who gets access to what spaces
   3. What are the conventions about space roles and user groups
6. List out what counts as a ‘routine change’—and make sure people know exactly how to handle them. Some examples:
7. 1. Updating options list for custom field
   2. Adding and updating field contexts
   3. Creating new projects with shared configuration
   4. Update user permission or association with project roles
   5. Updating the scope of Automation rules
   6. And more → the exact list of what you define as ‘routine changes’ can vary considerably. It all depends on your risk flexibility tradeoffs. The risk of errors and unintended consequences versus the wish to accommodate new business needs.
8. Decide your backup routines and recovery flows.
9. Spell out how both routine and one-off changes get managed: who can request, who approves, who does the actual work, and how it all gets tracked.

This checklist isn’t about giving you all the answers—it’s about making sure you’re asking the right questions and making intentional decisions.

Did I miss anything? Please share any additional elements here that you believe need to be included in any Atlassian Administration handbook

[s_gridnevskii]

I have backup by L1 support. In order to replace me when I am OOO or on vacation I document all procedures in Confluence. There is a bunch of articles like How to add user to Jira project with step by step manual with pictures that makes it virtually impossible to make a mistake. 

So my receipt is to document everything. As long as bosses define a policy - implement it first yourself and then leave clear instructions for everyone else.

Talking about Enterprise and high availability - of course one should have some kind of monitoring with warnings like CPU > 90% or low disk space. If properly tuned most issues may be prevented long before they in fact occur.

[graham_zabel]

Understand your Jira workflows and have a strategy for them. Do you want a small number of workflows for your organisation, or will you let every team have their own workflow? 

Jira workflows are a window into your teams' DevOps processes. Ideally most teams should work in a common, consistent way, hence their Jira workflows should be consistent. 

[Paul Stallworth]

Hi @Rina Nir 

It looks like this got double posted along with https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/What-should-be-included-in-the-Admin-handbook/ba-p/3091301.  

My advice would be reviewing these two posts as they have a wealth of knowledge built from experience in the trenches.  

https://community.atlassian.com/forums/Jira-Cloud-Admins-discussions/What-would-be-your-advice-to-first-time-Jira-Software-admins/td-p/711667

https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/What-would-be-your-advice-to-first-time-Jira-admins/ba-p/3084131

[Rina Nir]

@Paul Stallworth sorry for publishing twice. As I put articles drafts ahead of time- it could be that I get entangled in my own messiness.

Thanks for the references

[Rina Nir]

@graham_zabel I am with you 100%. In an enterprise environment you can't have each team 'do their own stuff'. If you want cross team collaboration you needs standards

[Rina Nir]

@s_gridnevskii Thanks for reminding us the pains of administrating a DC instance!

[s_gridnevskii]

@Rina Nir I have experience in both. And I would say DC is better since everything is under your control. If you need more performance - just add CPU and memory. If something crashes - you can investigate and resolve in minutes.

I recall having incidents in cloud Jira that lasted for hours with just a note "Sorry we have technical issues" and angry employees asking me every couple of minutes - when can we start working.

Also sometimes you need access to Jira database - DC allows it. It helped me when I was migrating from an old instance when they did not have GDPR and user names got messed up.