What should be included in the Admin handbook?

[#1]

I work a lot with Atlassian in regulatory-heavy environments, 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

[Kristian Klima]

+ the roadmap to the a) nearest, b) backup coffee machine :) 

[Haddon Fisher]

You hit all the high points! I might add a few things, but TBH they might be gold-plating:

- Disable team-managed projects.

- Create a documentation hub to hold stuff around not just "how to Jira" but "how to Jira in YOUR Jira" so that your users have a reference area on how the app works and what your local rules are.

- Set up regular clean-up patterns and cadences. Rules like "projects without updates in 1 year get archived" will seriously pay off down the road.

- Disable team-managed projects.

[Rina Nir]

@Haddon Fisher I double that: 'Disable team managed project'. Albeit, its controversial