Atlassian Admin Best Practices: A Guide for Jira and Confluence Admins

What Makes a Good Atlassian Admin?

Being an Atlassian admin is more than knowing where the settings are. The best admins think about the long game: will this permission scheme still make sense in two years? Will this custom field create confusion when the team scales? Will users actually be able to find what they need in Confluence?

This guide covers the practices that separate reactive admins (fixing things after they break) from proactive ones (building systems that don't break in the first place).

User Management

Use Groups, Not Individual Users

This is the single most important Atlassian admin practice. Always assign permissions to groups, never to individual users.

When you grant permissions to an individual and that person leaves the company, their access lives on until someone notices. With groups, you remove them from the group once and their access is revoked everywhere instantly.

Recommended group structure:

• ▹jira-admins — full system admin access
• ▹jira-project-admins — can manage projects but not system settings
• ▹jira-software-users — standard Jira Software access
• ▹jira-service-desk-agents — Jira Service Management agents
• ▹confluence-admins — full Confluence admin
• ▹confluence-editors — can create and edit pages
• ▹confluence-viewers — read-only access

Run a Quarterly User Audit

Every 3 months, check for:

• ▹Users who haven't logged in for 90+ days (deactivate, don't delete)
• ▹Users in groups that don't match their current role
• ▹Former contractors or vendors still with active accounts
• ▹Duplicate accounts for the same person

In Jira Cloud: Users → Manage users → sort by Last active. In Confluence: the same process. For Atlassian Cloud overall, use the Admin console at admin.atlassian.com.

Identity Provider Sync (SSO/SCIM)

If your organisation has more than 50 users, set up SSO and SCIM provisioning from your identity provider (Okta, Azure AD, Google Workspace). This automates user creation and — critically — deprovisioning when someone leaves. No more manually revoking access.

Jira Project Configuration

Standardise Your Project Templates

Left to their own devices, every project lead will create a slightly different project with different issue types, workflows, and screens. After a year you'll have 40 projects that all work slightly differently.

Create 3–5 standard project templates that cover your main use cases:

• ▹Software project — for engineering teams (Story, Bug, Task, Epic, Spike)
• ▹Operations project — for IT/ops work (Task, Incident, Change Request, Problem)
• ▹Service project — for internal support or customer-facing helpdesks
• ▹Simple project — for teams that just need a task list

Lock down who can create new issue types, workflows, and custom fields — these should go through the admin team, not be self-service.

Custom Fields: Less Is More

Every custom field adds overhead: it appears on screens, clutters search, and complicates migrations. Before creating a new custom field, ask: can an existing field serve this purpose? Can a label or component work instead?

Healthy custom field counts by instance size:

• ▹Under 50 users: fewer than 30 custom fields
• ▹50–200 users: fewer than 60 custom fields
• ▹200+ users: fewer than 100 custom fields

Anything above these numbers is a sign that project-level requirements have been solved with global fields when they should have used project-specific solutions.

Workflow Hygiene

Keep your workflows simple. A workflow with 12 statuses and 30 transition rules is a maintenance nightmare.

Good workflow design principles:

• ▹Fewer than 8 statuses per workflow where possible
• ▹Each status should have a clear meaning that any team member can explain
• ▹Transition conditions should be simple — avoid complex validator chains
• ▹Document every workflow with a diagram (Confluence is a good place to keep these)

Permission Schemes

The Minimal Permission Principle

Grant the minimum access needed for someone to do their job. Not the maximum you think they might need someday.

Default Jira Cloud permission scheme is fine for most projects. Only customise when you have a genuine security reason.

Common permission mistakes:

• ▹Giving all users "Project Admin" because it's easier than thinking about what they actually need
• ▹Giving anonymous users Browse Project access on internal tools
• ▹Creating a unique permission scheme for every project (use shared schemes)

Security Levels for Sensitive Issues

If certain issues contain sensitive information (HR matters, security vulnerabilities, executive-level projects), use Jira's Security Levels feature to restrict visibility within a project. This is more surgical than creating a separate project.

Confluence Administration

Space Governance

Every Confluence space should have: a defined owner, a clear purpose, and an audience. If you can't answer those three things for a space, it either needs an owner assigned or it should be archived.

Run a space audit every 6 months:

• ▹[ ] Every space has an owner in the Space Details
• ▹[ ] Spaces with fewer than 5 pages have been evaluated (consolidate or archive)
• ▹[ ] Spaces not updated in 6+ months have been flagged for archiving
• ▹[ ] Space home pages are current and link to key content

Storage Management

Confluence Cloud storage can grow quickly with large attachments. Common culprits: PowerPoint presentations attached to pages (link to a document tool instead), large video files (use a video platform), and duplicate uploads.

Monthly habit: Check Space → Space Settings → Storage Use. Any space using more than 5GB deserves a look.

Monitoring Instance Health

Jira Cloud Health Checks

Run these monthly:

• ▹Audit log review: Admin → Audit log — look for unusual bulk changes, permission modifications, or admin actions outside business hours
• ▹Automation usage: Admin → Automation — check rules approaching monthly execution limits
• ▹App review: Admin → Manage apps — any apps not updated in 6+ months are a risk
• ▹Performance: Are users reporting slowness? Check if any large JQL queries are running in dashboards or filters

The Admin Change Log

Keep a simple Confluence page (or Jira project) that logs every admin change: what changed, who made the change, why, and when. This is invaluable when troubleshooting unexpected behaviour. "When did this permission change?" becomes a 10-second question instead of an hour of digging.

Common Atlassian Admin Mistakes

Mistake 1: Giving everyone admin to avoid support requests — Creates security risk and makes audits impossible. Build proper self-service options (project templates, request forms) instead.

Mistake 2: Never cleaning up old projects — Abandoned projects pollute search results, confuse new users, and slow down global operations. Archive aggressively.

Mistake 3: Installing Marketplace apps without a review process — Every app is a potential security risk and a migration complication. Have a formal request and review process.

Mistake 4: No documentation of the admin setup — When you leave or take a holiday, someone else needs to manage the instance. Document your permission schemes, workflow logic, and non-obvious configuration decisions.

Mistake 5: Ignoring Atlassian deprecation notices — Atlassian regularly deprecates features and APIs. Check the Atlassian Cloud changelog monthly and plan for changes before they happen.

Need Atlassian Admin Support?

We provide on-demand and retained Atlassian admin services — from routine maintenance and user management to complex restructuring and migration projects.

Talk to an Atlassian admin specialist →