This is the first episode in a mini series designed to make Atlassian Guard feel simple, walking you through everything from the basics to advanced setup without drowning in menus.

Watch our full walkthrough video below for a visual tour of the Atlassian Admin Hub and Guard configuration screens:

The Problem Atlassian Guard Solves

One of the most common issues we see is admins trying to secure Jira separately, then Confluence separately, then someone adds Trello or Bitbucket, and suddenly identity rules, login policies, and audit visibility are inconsistent everywhere. It’s like running four different lock systems on one building while everyone shares the same front door. And it fails exactly when you need it most, during onboarding, offboarding, or security incidents.

If you want consistent access control, a clean user lifecycle, and centralized management, you need one place to handle it all. That’s precisely what Atlassian Guard is designed for. Instead of configuring security product by product, Guard lets you define policies once at the organization level and apply them across every Atlassian Cloud product your team uses.

What Is Atlassian Guard?

Atlassian Guard is a security and identity management layer for your Atlassian Cloud instance. It applies across Jira, Confluence, Bitbucket, Trello – essentially the entire Atlassian Cloud ecosystem. The most important thing to understand is this: Guard is an organization-level subscription, not a per-product add-on.

This means you manage Guard in your Atlassian Admin Hub at admin.atlassian.com under your organization, not inside a single Jira project, not inside a Confluence space. When you turn on single sign-on policies or provisioning rules, you do it once centrally and it affects managed accounts across your entire organization.

If you’ve ever wondered why you can’t find a particular security setting inside Jira, it’s probably because that setting lives at the organization level in the Admin Hub. In our video, we open the Admin Hub and walk through the dashboard where you can discover your current Atlassian Guard settings, see whether you already have a Guard Standard subscription, and explore the option to start a Guard Premium trial.

Atlassian Access vs. Atlassian Guard: Quick Clarity

Atlassian Guard didn’t appear out of nowhere. It’s mostly a rebrand and expansion of capabilities you may already know. Here’s the timeline:

• Atlassian Access became Atlassian Guard Standard around June 2024.
• Atlassian Beacon became Atlassian Guard Premium in October 2024.

So if you’ve been searching for Atlassian Access, you’re not lost, you’re just looking at the old name for the same core identity foundation, now with additional security capabilities layered on top.

Why the Rename?

Atlassian expanded beyond just access control, meaning not only login and identity. Guard now includes things like data protection and threat detection. In other words, it’s not only about who can log in, but also what data is sensitive and what risky behavior is happening across your organization.

Guard Standard vs. Guard Premium

Think of it this way: Guard Standard is your identity backbone, while Guard Premium adds the security operations layer including data security and threat detection. Let’s walk through what each tier includes at a high level.

Guard Standard Features

Guard Standard provides the foundational identity and access management controls that most organizations need as a starting point:

• Domain Verification and Account Claiming, This is how you prove you own your company domain (e.g., example.com). In our video, we navigate to Directory and Domains in the Admin Hub to show a domain that has been added and is going through the verification process. After domain verification, you turn users with that email domain into managed accounts, which are what you can actually control and secure consistently.
• Single Sign-On (SSO), Your users authenticate through your identity provider such as Microsoft Entra ID or Okta, giving you centralized login control. If you have compliance requirements, this is often step one. In the Admin Hub, you find this under Security and Identity Providers.
• User Provisioning via SCIM, This is the automation piece. SCIM will create accounts, update attributes, and deactivate users automatically from your identity provider. This is what prevents ghost accounts and the classic offboarding scramble where departed employees retain access.
• Authentication Policies, This is where you set rules such as whether a domain requires multi-factor authentication. You can control how users sign in with one policy applied consistently across the organization. You can also configure settings around API token usage here.
• Mobile App Management, Helps you manage mobile access to Atlassian apps with organization-level controls. You can create mobile app policies under Security, Device Security, and Mobile App Policies.
• Audit Log, When something goes wrong or an auditor comes asking questions, the audit log helps you answer who did what, when, and where. You find this under Insights and Audit Log in the Admin Hub.

Guard Premium Features

Guard Premium is where you move from identity controls into deeper security and data protection. It typically includes:

• Data Classification (Sensitivity Labels): This lets you label content as public, internal, or confidential and treat it differently based on that classification.
• Sensitive Data Detection: Automatically scans for risky content like credit card numbers or exposed API tokens so you can find problems before they become incidents.
• Threat Detection and Activity Alerts: Can alert you when something looks like unusual login patterns or risky behavior that doesn’t match normal usage.
• Data Security Policies: Allows you to define and enforce rules around how sensitive data is handled across your organization.
• Extended Audit Logs and SIEM Integration: Security Information and Event Management integration means your central security monitoring system can receive Guard events, feeding them into your broader security tooling.

Two important points about Premium. First, it’s designed for teams handling sensitive data, regulated industries, or serious compliance requirements. Second, and this trips people up, Premium is an add-on to Standard. You generally need Guard Standard first, then Premium layers on top of it.

Atlassian Guard Pricing

Understanding the pricing model is essential before you commit. Here’s the current breakdown:

• Guard Standard is listed at $4 per user per month on any plan. It’s included with Atlassian Cloud Enterprise.
• Guard Premium is listed at $8 per user per month as an add-on to Standard.
• There is typically a free 30-day trial available for Guard.

The key billing detail to understand is that Guard is billed per managed account across your organization. Think of it as: who is managed under my domain and policies? That’s the account that matters for billing purposes.

Your Next Steps

Getting started with Atlassian Guard doesn’t have to be overwhelming. Here are three simple steps to take right now:

• Step 1: Go to admin.atlassian.com, open your organization, and find the Guard section. Just confirm what you have today.
• Step 2: If you’re not on Guard yet, start a 30-day trial and plan your rollout, especially if you’re going to claim accounts and enforce single sign-on.
• Step 3: Watch the next episode in our series where we start with the foundation: verifying your domain and claiming accounts. Everything else in Guard builds on that.

If you’re already using Atlassian Access, this is your product now, and there’s a lot of powerful new functionality to explore. Stay tuned for the rest of our mini series where we’ll do detailed setup walkthroughs and demos covering domain verification, account claiming, SSO configuration, SCIM provisioning, and Guard Premium features like data classification and threat detection.

We hosted a live webinar demonstrating exactly how to configure these delegation rules inside Jira so your system understands who is responsible at all times, automatically.

Watch the full walkthrough in our webinar recording below:

The Real Problem: Jira Doesn’t Understand Your Shift Schedules

Most teams today manage their rotations and shift schedules outside of Jira. They rely on Confluence pages with rotation lists, Slack or Teams messages announcing who is on call this week, or Outlook and Google Calendar reminders that pop up on Monday mornings. The issue is that while these tools communicate shift changes to people, Jira itself has absolutely no awareness that anything has changed.

The result is predictable and painful. New tickets still get assigned to the wrong person. Approvals continue routing to someone who is offline or no longer on shift. Round-robin automations don’t exclude unavailable users. And ultimately, admins end up spending significant time manually reassigning issues every week — a process that simply does not scale, especially in larger organizations with frequent shift changes.

Human Memory Is the Weakest Link

Even when teams try to be disciplined about updating assignments, humans forget. Someone forgets to update the assignment role. Someone forgets to change the automation configuration. Someone forgets to reassign approvals. It only takes one missed handover for tickets to pile up, SLAs to breach, and customers to wait longer than they should. The core issue is that the process depends on human memory, and that is inherently unreliable.

What Is Permanent Delegation?

Permanent delegation means defining structured coverage in advance so that your Jira environment automatically knows who covers whom, when coverage applies, which issues are affected, and whether the covering person replaces the assignee, watcher, or approver. Once these structures are set up, everything works automatically, no weekly reminders, no manual cleanup, no Slack announcements, and no Outlook reminders.

This approach transforms Out of Office Assistant from a simple leave management app into a structural reliability tool designed for operational continuity, shift coverage, rotation coverage, and on-call coverage.

Live Demo: Automating Shift Handovers in Jira

In our live demonstration, we walked through a practical scenario. We have a support engineer called Alex whose shift has ended, and Maria is taking over his shift for the week. Instead of manually reassigning all of Alex’s tickets, we configured a permanent delegation rule to handle this automatically.

Setting Up the Delegation Rule

Using the Out of Office Assistant user administrator view, we accessed Alex’s profile and created a rule with the following configuration:

• The rule runs from Monday to Monday, covering the full week that Alex is off shift
• A JQL filter scopes the rule to only reassign work items that are not in “Done” status, because there is no need to reassign completed tickets to Maria
• Maria is set as the coverer, meaning all qualifying issues assigned to Alex will automatically transfer to her
• Since this is a regular occurrence and both team members are aware of the rotation, no comment message is required, though one can be added if needed

When we created a new ticket and assigned it to Alex, the system immediately reassigned it to Maria without any manual intervention. This happens automatically the moment the ticket is created or when the delegation rule’s date range becomes active.

Bulk Assignment for Immediate Updates

An important feature we highlighted is the bulk assign capability. If you create a rule where the start date has already passed, for example, you set it up on Thursday but the shift started on Monday, you can click the bulk assign button to immediately reassign all qualifying issues. Without this, the rule would only apply to new issues going forward from the moment of creation.

Approval Delegation in Jira Service Management

We also demonstrated how permanent delegation works for approvals in JSM. Using the same Monday-to-Monday timeframe, we set up a rule specifically for a Jira Service Management project where instead of selecting a coverer for assignments, we selected Maria as the approval delegate. When a new ticket was created that required Alex’s approval, the system automatically set Maria as the approver, ensuring no approval requests sit blocked while Alex is off shift.

Recurring Templates with Calendar Integrations

Because shift rotations are often recurring, Out of Office Assistant supports templates that integrate with Outlook, Google Calendar, Slack, and Zapier. For calendar-based templates specifically, you can configure a template once with your project scope, coverer, and message, and then use it repeatedly through your Outlook or Google Calendar. This means Alex can set up his every-other-week rotation as a recurring template and never have to manually configure the rule again.

Enterprise-Scale Scenarios

24/7 Regional Support Coverage

For global teams, permanent delegation enables time-based delegation chains. For example, Berlin handles support from 8:00 to 16:00, New York takes over from 16:00 to midnight, and Sydney covers midnight to 8:00. Instead of manually transferring tickets between regional teams, the system ensures that if Berlin does not resolve a ticket during their shift, it automatically moves to the New York team, and then onward to Sydney. Coverage flows seamlessly across time zones.

Weekly On-Call DevOps Rotations

In DevOps environments where a different engineer handles escalations each week, permanent delegation removes the need to manually update rotation assignments. You define the recurring rules once, and the system ensures the correct person receives escalation tickets each week without anyone having to remember or announce the change.

Backup Approvers for Leadership Workflows

When executive approvals are required and a VP or director is unavailable, critical decisions can be delayed for days or even weeks. With permanent delegation, you can configure a backup approver who automatically receives approval requests when the primary approver is out. No escalation gets blocked, and time-critical decisions stay on track.

Governance and Accountability

For larger organizations with specific hierarchies, automation alone is not enough, teams also need governance and traceability. The delegation rules created in Out of Office Assistant are visible and auditable, meaning you can trace exactly who was responsible for what and when. This accountability is valuable not only for internal reviews but also for compliance and audit purposes. When delegation is set up from the beginning with clear rules, mistakes are significantly reduced.

The Cost of Manual Delegation

We can quantify the impact of manual handover work. If an admin spends just two hours per week fixing assignments, that adds up to approximately 8 hours per month and 96 hours per year, more than two full working weeks spent solely on maintaining coverage manually. Now multiply that across multiple teams, and the overhead becomes substantial.

Permanent delegation eliminates this wasted time and, more importantly, it protects your SLAs, reduces ticket aging, prevents approval deadlocks, and improves your overall customer experience. It is not just a matter of convenience, it is about operational resilience.

Getting Started with Out of Office Assistant

If your team runs on shifts and Jira does not understand those shifts, you are running on risk. Permanent delegation removes that risk entirely. Out of Office Assistant for Jira and JSM is available on the Atlassian Marketplace where you can download and evaluate it for your own environment. The app supports both standard Jira projects and Jira Service Management projects, with integrations for Outlook, Google Calendar, Slack, and Zapier.

If you would like a personalized walkthrough tailored to your specific use case, our support team is happy to schedule a demo and help you understand exactly how the app can solve your shift rotation and delegation challenges. Simply reach out to our team and we will guide you through a setup that fits your workflow.

This guide covers everything from creating custom fields and field configurations to setting up screens, permission schemes, space roles, issue security levels, and using the audit log to track admin changes.

Watch our full walkthrough in the video below:

Fields: The Data You Capture on Issues

Fields are the foundation of every Jira issue. They represent the data you capture each time a work item is created or updated. Jira comes with a set of standard fields out of the box, including Summary, Description, and Priority. These cover the basics for most workflows, but as your organization’s needs grow, you’ll likely want to extend them.

That’s where custom fields come in. As admins, you can create custom fields such as dropdowns (select lists), date pickers, user pickers, and status-like custom fields. In our video, Marvin demonstrates how to create a new field by navigating to the fields section under Jira work items, clicking “Create new field,” selecting the field type, giving it a name, and optionally adding a description so other users understand its purpose.

The Danger of Too Many Fields

One of the most important warnings we share in this video is about field sprawl. Creating too many fields is one of the fastest ways to make Jira slow and confusing for end users. Every custom field you add increases the complexity of your instance, impacts performance, and can clutter create and edit screens. The rule of thumb is simple: only create a field when you genuinely need and will use the data it captures. If you’re not actively reporting on or filtering by a field, reconsider whether it’s necessary.

Field Configurations: Rules for Your Fields

Once you have your fields in place, the next layer of control is field configurations. Field configurations determine the rules that govern each field’s behavior. Specifically, they control whether a field is required, hidden, or given a default value.

This is a powerful tool for simplifying the issue creation form. For example, you can hide rarely used fields so they don’t overwhelm users during issue creation, and you can mark only the essential fields as required. This strikes the right balance between capturing important data and keeping the user experience clean and efficient.

It’s important to understand the distinction here: field configurations define the rules about fields, while screens (covered next) define what users actually see. These are two separate but complementary layers of configuration.

Screens: What Users Actually See

Screens are one of the most impactful configuration elements in Jira. They control which fields appear on the Create, Edit, and View screens for issues. This means you have granular control over what information is presented to users at different stages of interacting with a work item.

In our demo, Marvin shows how screens are created per space and how you can tailor the user experience for different teams or workflows. The key distinction to remember is that field configurations control the rules (required, hidden, default), while screens control visibility. You might have a field that exists and is optional per the field configuration, but it won’t appear to users unless it’s added to the relevant screen.

By carefully managing your screens, you can ensure that users only see the fields that are relevant to their workflow, reducing confusion and improving data quality.

Permissions: The Security Side of Jira

Permission schemes represent the security backbone of your Jira instance. They define who can perform specific actions, including browsing spaces, creating work items, editing work items, transitioning work items through workflows, and administering spaces.

Permissions can be assigned through multiple mechanisms: groups, space (project) roles, or specific individual users. While assigning permissions to specific users might seem straightforward, it doesn’t scale well. This is where space roles become essential.

Space Roles and Scalable Permission Management

Space roles such as Administrator, Developer, and Viewer are assigned at the space (project) level and then referenced in permission schemes. This approach is what makes access control consistent and scalable across your entire Jira instance. Instead of managing permissions user by user, you assign users to roles within each space, and the permission scheme handles the rest.

In our demo, Marvin navigates to the space settings to show how space roles are configured and how they connect back to the permission scheme. This architecture means that when you need to change who can do what, you update the role assignment rather than rewriting permission rules, saving significant administrative effort.

Issue Security: Restricting Visibility for Sensitive Work

Sometimes you need to go beyond standard permissions and restrict who can see specific issues within a space. This is where issue security levels come in. Issue security allows you to limit visibility of sensitive work items to only certain users, groups, or roles, even within a space where others normally have browse access.

Issue security is configured through an Issue Security Scheme, which you associate with a specific space. As Marvin points out in the video, this feature may not be enabled by default. You’ll need to navigate to the space settings, go to the work item security section, and either select an existing scheme or create a new one. This is a critical step for teams handling confidential or sensitive information within shared Jira spaces.

The Audit Log: Tracking Admin Changes

One feature that’s often overlooked but incredibly valuable is the audit log. The audit log tracks all admin changes in your Jira instance, recording who changed what and when. This is essential for both troubleshooting and governance.

In our video, Marvin navigates to the Jira admin system settings under troubleshooting to show the support audit log. There you can see entries such as when a custom field was created and by which account. If something breaks or an unexpected change appears in your instance, the audit log is your first stop for investigation. Make it a habit to check this log regularly, especially after configuration changes.

Putting It All Together: Your Next Step Exercise

Now that you understand the layers of Jira configuration, from fields and field configurations to screens, permissions, and security, it’s time to apply this knowledge. Our recommended next step exercise is straightforward and high value:

• Open one real space in your Jira instance
• Identify the Issue Type Scheme assigned to it
• Identify the Workflow Scheme in use
• Identify the Permission Scheme applied

Reviewing these three schemes for a single space will teach you an enormous amount about how your Jira instance is wired. You’ll see how issue types, workflows, and permissions interconnect, giving you a practical understanding that goes far beyond theory. Combined with the knowledge from the earlier parts of this series, covering space admin basics, work item types, and workflows, you now have a complete roadmap for managing Jira as an admin with confidence.

This is Part 3 of our Jira Admin Essentials series, where we focus specifically on the project-level settings that control what work looks like and how it flows through your system.

In our video, Marvin, a Technical Support Engineer in DevOps at re:solution GmbH, walks through each of these settings live in a demo instance so you can see exactly where they live and what they control:

Project Settings Overview: Where Day-to-Day Admin Happens

Most of your day-to-day Jira administration will happen inside a space (project). To access these settings, you navigate to your project, click the three dots menu, and select space settings. From the detailed settings panel, you can perform several foundational tasks that every admin should be familiar with.

Here’s what you can manage from the project settings screen:

• Rename the project, Update the display name of your space at any time.
• Find the project key, This is critical for JQL searches, reporting, and any database-level actions you might perform later.
• Set the team type or project category, Helps organize spaces across your organization.
• Change the project owner, Assign ownership to the appropriate person.
• Update the project avatar/icon, A visual identifier that helps users quickly recognize the space.

These are simple but important configurations that set the foundation for everything else in the project.

Work Item Types (Issue Types)

Work item types define what work items look like within a space. Out of the box, Jira provides types like Epic, Story, Task, and Bug. However, you also have the ability to create custom work types tailored to your organization’s needs, for example, a Change Request or a Support Ticket.

To create a new work item type, the fastest method shown in our video is to use the administration panel. Navigate to the work items section, select work types, and click the option to add a new work type. You’ll give it a name, and you can immediately assign it to a work type scheme. The process is straightforward, and it gives you the flexibility to model your Jira instance around how your teams actually work.

Understanding Schemes: Why Projects Don’t All Look the Same

A scheme is one of the most important concepts for Jira admins to understand. In essence, a scheme is a collection of work item types that gets assigned to a space. This means different spaces can display different work item types based on what’s relevant to their team.

For example, a software project can focus on Epics, Stories, and Bugs, while a support project can focus on Incidents and Requests. This separation provides several key benefits:

• Fewer options, Users only see the work item types that are relevant to their space.
• Less confusion, Teams aren’t overwhelmed by types they’ll never use.
• Cleaner reporting, Data is more meaningful when it’s not cluttered with irrelevant item types.

Schemes are also how Jira determines which workflows apply to which issue types within a project. This layered configuration model is what makes Jira so powerful, but it’s also where things can get complex if you’re not careful.

Screens: Controlling What Users See

Screens define which fields appear to users when they create or edit a work item. In our video, we navigate to the screens section within the space settings under request management. You’ll see the screens that have been added by default, as well as any that were configured later for that specific space.

Screens connect into the overall scheme model, meaning they’re part of the broader configuration that determines the user experience at the project level. Understanding where screens are configured helps you control what information is collected and displayed at each stage of a work item’s lifecycle.

Workflows: How Issues Move Through Statuses

The Basics of Workflow Configuration

Workflows define how a work item moves through statuses, typically from To Do, to In Progress, to Done. In our video, Marvin demonstrates this by opening an example workflow and clicking edit workflow, which launches a visual editor.

The workflow editor provides a drag-and-drop UI where you can modify statuses and define transitions between them. You can specify what happens after a status like To Do, or what conditions must be met before a work item can move to Done. This visual approach makes it much easier to design and understand complex workflows.

Different Work Item Types Can Have Different Workflows

One of the key things to understand is that different work item types can follow entirely different workflows within the same space. For instance, a Bug might include extra steps like a quality review stage or a “Ready for Release” status, while a simple Task can follow a minimal To Do → In Progress → Done path. This flexibility allows you to tailor the process to the nature of the work.

The Big Admin Gotcha: Workflow Schemes and Shared Impact

This is perhaps the most critical takeaway from this entire video: spaces don’t own workflows directly. Instead, they use workflow schemes, and those schemes can be shared across multiple spaces.

This means that if you edit a workflow scheme, your change might impact not just the space you’re looking at, but every other space that uses that same scheme. This is what’s sometimes referred to as the “blast radius” of a configuration change. The golden rule for any Jira admin is simple: always check where a scheme is used before editing it. Taking a moment to verify shared usage can save you from accidentally disrupting workflows across your entire organization.

What’s Coming in Part 4

In the next part of our Jira Admin Essentials series, we’ll cover the other half of space configuration, specifically fields, screens in more depth, and permissions. These are the settings that control what users see on their work items and what they’re allowed to do within a space. Stay tuned for Part 4, where we dive deeper into the configuration layers that shape the complete Jira admin experience.

This is Part 2 of our Jira essentials series, where we focus specifically on the elements that directly affect security and cost within your Atlassian Cloud environment.

In our video, Marvin, a Technical Support Engineer (DevOps) at re:solution GmbH, walks through each of these concepts step by step in a live demo instance:

Where Jira Cloud User Management Actually Lives

One of the first things to understand about Jira Cloud is that user management does not happen inside Jira itself. Instead, it is handled through your Atlassian Organization at admin.atlassian.com. This is a centralized admin console where you manage users, groups, product access, and more across all your Atlassian Cloud products.

To get there from Jira, click the gear icon in the top-right corner of your Jira instance and select “User management.” You will be automatically forwarded to admin.atlassian.com, where you may need to select your matching site if you manage multiple sites. If you only manage one site, it will be selected automatically. Once inside, you will find the Directory section, which contains both your users and groups.

How to Add or Invite a New User

Adding a new user to your Jira Cloud instance is straightforward once you know where to look. Inside the Directory under user management, you will see a list of all existing users in your organization. To invite someone new, simply click the blue “Invite users” button.

From there, the process is simple:

• Enter the email address of the person you want to invite
• Choose which app access the user should receive right away (for example, Jira Software, Jira Service Management, or Confluence)
• Click next and confirm

That is all it takes. The invited user will receive an email and can begin accessing the products you have granted them access to. This initial access selection is important because it ties directly into licensing, which we cover in more detail below.

How Groups Work and Why They Matter

Groups are the foundation of how you assign permissions and manage access in Jira Cloud. Rather than configuring access for each individual user, you assign users to groups, and then grant those groups the appropriate permissions and product access. This approach makes onboarding, offboarding, and permission changes far more consistent and manageable.

Common Default Groups

When you first set up Jira Cloud, you will notice some default groups already in place. Two of the most common are:

• jira-administrators – grants admin-level access to Jira
• jira-software-users – grants standard Jira Software access

These groups are used throughout permission schemes and product access settings, so understanding their role is essential for any Jira admin.

Creating a Custom Group

In our video, we demonstrate how to create a custom group called “Developers.” This is useful when you want to manage a specific team’s permissions and product access as a unit. Here is how to do it:

• Navigate to Directory and then select “Groups”
• Click “Create group”
• Give the group a name (in our case, “Developers”) and optionally add a description
• Save the group

Once the group is created, you can immediately start adding members to it. Simply search for existing users within your instance and click “Add” to include them in the group. You can add multiple users, and from that point forward, any permissions or product access assigned to the “Developers” group will automatically apply to all its members.

This group will also be used later in permission schemes, which we will cover in a future part of this series. The key takeaway is that groups give you a clean, repeatable model for managing who can do what across your Atlassian products.

Product Access and Licensing Control

Product access, also referred to as application access, is where you control which users can access specific Atlassian products like Jira Software, Jira Service Management, or Confluence. This is critically important because it directly affects your licensing costs. Every user who has access to a product counts toward your license, so keeping access tight is essential for cost management.

Managing Product Access

To manage product access, open the app settings and navigate to Atlassian apps. Here you will see all the Atlassian products associated with your site. In our demonstration, we focus on Jira Service Management (JSM) and click “Manage app” to see which groups currently have access and what roles are assigned.

Each product allows you to define which groups grant access and what role those users receive within the product. For Jira Service Management specifically, the available roles include:

• Customer – external users who submit and track requests
• Stakeholder – users who can view but not directly work on issues
• User/Agent – full agent access to work on service desk tickets
• User access admin – users who can manage access for others

Assigning a Group to a Product

In our video, we add the newly created “Developers” group to Jira Service Management and assign the agent role. The process is simple: click “Add group,” search for your group, select the appropriate role, and click “Add.” From that moment on, every user who is a member of the “Developers” group will automatically receive agent access to Jira Service Management.

This is extremely powerful because it means you no longer need to manually configure product access for each individual. When a new team member joins and is added to the “Developers” group, they automatically get the correct product access. When someone leaves and is removed from the group, their access is revoked just as easily.

Why Tight Access Management Matters

If you do not manage product access carefully, several problems can arise that affect both your budget and security:

• License costs creep up – users who do not need access to a product still consume a license seat, increasing your monthly or annual bill
• Access becomes inconsistent – without a group-based approach, some users may have more access than they need while others lack what they require
• Onboarding and offboarding become manual work – without groups, every new hire or departure requires individual configuration across multiple products

By combining groups with product access rules, you establish a structured access model that scales with your organization. New users are simply added to the appropriate groups, and everything else follows automatically.

What Comes Next

In Part 3 of this series, we will move into space configuration, covering workflows, screens, work types, and permissions. That is where Jira truly becomes a powerful tool tailored to your team’s specific processes. The groups and access model we established in this part will play a direct role in how permissions are configured moving forward, so having a solid foundation here is critical for everything that follows.

This is the first in a series of Jira essentials videos designed to give new admins a beginner-friendly overview of the platform without unnecessary complexity.

Watch our full walkthrough of Jira’s admin panel essentials in our video below:

The Two Types of Jira Admins (and Why It Matters)

Before diving into the settings themselves, it’s critical to understand that Jira has two distinct types of administrators, each with different levels of access and responsibility. Confusing the two is a common mistake new admins make, and understanding this distinction early will save you a lot of frustration down the road.

Site/System Admin

The Site or System Admin has control over the entire Jira platform. This includes global settings, user management, security configurations, and app installations. You access these settings by clicking the gear icon in the top-right corner of Jira and selecting “System.” Everything you see in this area applies platform-wide, meaning any changes you make here will affect all users and all projects across your entire Jira instance.

Project/Space Admin

The Project or Space Admin, on the other hand, has a much narrower scope. Their settings apply to one specific project or space only. This includes permissions, workflows, and work item types, but only for that particular project. In the video, Marvin demonstrates this by opening a support space, showing that the configuration options available there are limited to that single space’s look, feel, and permissions.

The key takeaway here is simple: the site admin controls the platform, while the space admin controls one space. In this article and video, we focus exclusively on the site admin and global settings. A future video in the series will cover project and space administration in detail.

Quick Tour: Jira Global Settings Highlights

Once you’re in the global administration area (accessed via the gear icon → System), you’ll find a range of configuration options. While many of these are perfectly fine left at their default values, knowing where they live and what they do is essential for any new admin. Let’s walk through the most important ones.

General Configuration

The General Configuration section is your starting point in the global admin area. Here you can adjust foundational settings that affect how your Jira instance operates at a base level. Key options include:

• The base URL of your Jira instance
• The template used for outgoing email notifications
• The default user time zone
• The default language for the platform

As demonstrated in the video, Jira comes with several languages installed by Atlassian by default, and you can change the default language based on the needs of your user base. This is particularly useful for international teams or organizations that operate in a language other than English.

Look and Feel (Branding)

The Look and Feel settings are where you can customize the visual presentation of your Jira instance. This section allows you to change:

• Navigation colors
• Date and time formats
• Your instance’s logo or icon

This is particularly useful for branding purposes. If your organization wants Jira to reflect company colors or display a corporate logo, this is where you make those changes. It’s a small touch, but it helps users feel like the tool is tailored to their organization rather than a generic out-of-the-box experience.

Default User Preferences

The Default User Preferences section allows you to set sensible defaults for users who haven’t yet customized their own personal settings. This is important because when a new user logs into Jira for the first time, they’ll inherit whatever defaults you’ve configured here. Options you can control include:

• The outgoing email format (HTML or plain text)
• The number of work items displayed per page
• Other default UI behaviors

Setting these defaults thoughtfully means fewer support requests from new users who might otherwise be confused by the default experience. It’s a proactive step that can significantly improve the onboarding experience for your team.

Default Dashboard

If you’re already familiar with Jira dashboards, you might skip this section, but if you’re new to the platform, the Default Dashboard is worth understanding. Every user in Jira can build their own personalized dashboard, but there’s also a default dashboard that serves as the starting point for users who haven’t created one yet.

In the global settings, you can configure the look and layout of this default dashboard. This is a great way to ensure that first-time users see relevant information, such as key project updates, assigned issues, or activity streams—right when they log in.

Announcement Banner

One of the most practical tools in the global admin settings is the Announcement Banner. This feature allows you to display an instance-wide message to all users across your Jira platform. Common use cases include:

• Maintenance notices and scheduled downtime
• Outage notifications
• Policy reminders or important updates

In the video, Marvin demonstrates creating a banner by entering a text message, selecting a banner color, and choosing whether users can dismiss the banner or whether it remains persistent. You can also decide if the banner should be public. Once you click “Publish,” the banner appears at the top of the Jira interface for all users. If you’ve enabled the dismiss option, users can click the X to close the banner on their end.

This is a simple but powerful communication tool that every Jira admin should know about, especially during planned maintenance windows or when rolling out changes to the platform.

Why Knowing These Settings Matters

As Marvin points out in the video, most of these global settings are perfectly fine left at their defaults. You don’t need to tweak everything on day one. However, as a new Jira admin, simply knowing where these controls live is invaluable. It saves time and reduces panic when situations arise, such as:

• Users complaining that “Jira looks weird“, you’ll know to check the Look and Feel settings
• Needing to announce a maintenance window,  you’ll head straight to the Announcement Banner
• The default experience needing cleanup for new users, you’ll adjust Default User Preferences and the Default Dashboard

The areas you’ll likely interact with most frequently as your admin journey progresses are user management and project or space configuration. These are the settings that directly impact day-to-day operations, licensing, and team access.

What’s Coming Next

This video is the first in our Jira essentials series. In part two, we will tackle user management, the settings that impact single sign-on (SSO) and licensing. These are critical areas for any Jira admin, as they directly affect who can access your instance and how your licensing costs are managed. Make sure to follow along with the series to build a comprehensive understanding of Jira administration from the ground up.

This approach eliminates the guesswork around whether your automated tasks actually completed, giving you a provable trail that satisfies auditors, stakeholders, and your own operational confidence.

In our video, we demonstrate the full setup process step by step, from creating the Jira Automation rule to testing the webhook end to end:

Why Success Notifications Matter

Failures get attention. When something breaks, alerts fire, tickets get created, and people scramble to fix the problem. But success usually goes unnoticed – and that silence can be a liability. When someone asks, “Did the automated cleanup run last night?” and your answer is “I think so,” you have a gap in your operations.

As Marvin, Technical Support Engineer (DevOps) at re:solution GmbH, puts it in our video: successful automations are quiet, but auditable automations are what truly matter – because auditors are not quiet. The core problem breaks down into three missing elements:

• Traceability – When did the automation run?
• Visibility – Is it healthy and functioning correctly?
• Evidence – What happened next after it completed?

By treating success events as first-class signals, you close all three of these gaps with a single webhook configuration.

The Solution: Automated Task Succeeded Webhook Trigger

The app supports a webhook trigger called “Automated Task Succeeded.” This means that when a task completes successfully, it can notify Jira Automation via an incoming webhook, and Jira can then do something useful with that success signal. This is not about celebrating success, it is about proving success with a trail you can point to.

Three Common Patterns for Success Notifications

There are three primary patterns you can implement once you have a success webhook in place:

• Update a dashboard – Reflect status, timestamp, and run count on a live dashboard so anyone can see at a glance whether automations are healthy.
• Write an audit log – Create a ticket, comment, or log entry that serves as a permanent record of the successful run.
• Chain workflows – Use the success signal to trigger a follow-up workflow, such as “Task A succeeded, now start Workflow B.”

In our video, we implement a simple version of the second pattern: creating a Jira work item on success. This is easy to expand later into any of the other patterns.

Step-by-Step Setup: Creating the Jira Automation Rule

The first step is to create the automation rule within Jira at the project or space level. Navigate to your target project or space, then go to Space Settings and select Automation. The automation rule you create here will be scoped only to that specific space.

Configuring the Incoming Webhook Trigger

Start by adding a trigger and selecting Incoming Webhook. After you enable or save the rule, Jira will display two critical pieces of information: the Webhook URL and a Secret. You will need both of these later when configuring the app side of the integration.

One important setting to note: you must change the configuration to “No work items from this webhook.” This allows the automation rule to run without requiring an existing issue context, which is essential since the webhook is firing from an external event rather than from within an existing Jira issue.

Defining the Action

For the action, we set up a Create Work Item step. This creates a new task (or whatever issue type fits your needs) with a summary like “Automated task succeeded” and a short description providing context about what ran and where to verify. In our demonstration, this keeps things simple, but you could replace or extend this action to update a Confluence or Jira dashboard, add a row to a structured log, send a daily digest, or trigger an entirely separate workflow.

Step-by-Step Setup: Adding the Webhook in the App

The second major step is configuring the webhook on the app side. Navigate to the user management app, go to Settings, and find the Atlassian Automation Webhooks section. Click “Add Webhook” and give it a descriptive name such as “Automated Task Succeeded.”

Now paste in the Webhook URL that you copied from the Jira Automation rule, along with the Secret. For the trigger selection, choose “Task success” or “Automated Task Succeeded”, this is the event that will fire the webhook when an automated task completes successfully.

We recommend adding notes to the webhook configuration as well. These notes are visible to other admins and help provide context about what this webhook does and why it exists. Ensure the webhook is set to Active, then save your configuration.

Testing and Verifying the Setup

With both sides configured, it is time to run a test to confirm everything works end to end. Trigger a test webhook for the “Task success” event from within the app. After running the test, there are two places you need to verify the results.

Check the Jira Automation Audit Log

First, go to the automation audit log in Jira. You should see that the incoming webhook was triggered and that the corresponding action, in our case, creating a work item, was executed successfully. Expand the log entry to see the full details of what happened during the automation run.

Verify the Work Item

Second, check your queue or board to confirm the new work item was actually created. Verify that the summary and description match what you configured in the automation rule. In our video, we confirmed that both fields populated correctly, matching the automation rule we defined earlier.

Once you have verified everything works, you can expand the setup. Assign created items to a specific person, add labels or components, or trigger additional workflows based on the success signal.

Operational Tips for Managing Success Notifications

One common concern with success notifications is noise. If you have automations running frequently, success triggers can generate a high volume of notifications that overwhelm your channels. The key recommendation from our video is: do not turn off success notifications, route them smarter.

For example, you can log every single success event for audit purposes, but only send a notification to your Slack or Teams channel once per day with a summary. This gives you complete traceability in your logs while keeping your communication channels clean and actionable.

Your Next Steps

To get started with success webhooks in your own environment, follow these steps:

• Pick one pattern to implement first: dashboard update, audit log, or workflow chaining.
• Create the incoming webhook automation rule in Jira at your project or space level.
• Add the webhook in your app’s notification settings with the correct URL, secret, and trigger.
• Run one manual test today to confirm the full flow works.

Once this is in place, you stop guessing whether your tasks ran and start knowing, with proof you can point to whenever anyone asks.

Our approach streamlines complex contractor offboarding or security event responses by using a controlled, filter-based safety net for administrative scale.

Watch our step-by-step walkthrough in our video to see this process in action within the Atlassian interface.

The Reality of Administrative Overload in Atlassian Cloud

In our video, we address a common struggle for IT admins: the request to suspend a very specific group of users without affecting the rest of the organization. We often see admins buried under spreadsheets, clicking through hundreds of individual profiles to verify access levels. This manual approach is a recipe for what we call “big admin weekends,” where a supposedly small task turns into a lengthy recovery project due to human error or outdated data.

We believe that targeted filters are the ultimate safety net for any administrator. When you are tasked with offboarding contractors or responding to a security event, the goal is to be fast and consistent. By using the methods we outline, you can transform a tedious afternoon of manual clicks into a five-minute task. Our technical support engineers at re:solution GmbH spend their days preventing these inefficiencies, ensuring that your user data remains clean and your security posture stays strong.

Critical Distinctions: Suspend User vs. Remove App Access

Before clicking any buttons in the admin UI, it is vital to understand the difference between two actions that are frequently confused. In our video, we emphasize that removing app access is not the same as suspending a user. Removing access simply detaches the user from a specific product like Jira or Confluence, but the account remains active in the system. While this might save on seat costs, it does not fully block access across the entire Atlassian service suite.

On the other hand, suspending a user is a much stronger and more immediate action. This is the “stop access now” operation. It completely blocks the user from all Atlassian services, invalidates their active sessions, and stops any automated integrations they might own. In this tutorial, we focus on suspension because it is the most effective way to handle high-stakes scenarios like contractor offboarding or security remediation where you need a hard stop on all user activity.

Step 1: Eliminating Stale Data with a Manual Sync

One of the biggest “gotchas” for Atlassian admins is relying on stale data. If a user’s access status changed just a few minutes ago, your current view in the admin portal might not yet reflect those changes. Running a bulk operation on outdated information can lead to suspending the wrong people or missing those who should have been included. This is why we recommend a manual sync as your first step.

We treat this sync as a “trust reset.” By navigating to the User Browser and initiating a fresh sync, we ensure that every filter we apply later is working against the absolute latest state of our user directory. While the sync runs, you can see the progress of the steps involved and how long it will take. Waiting those few extra seconds provides the data integrity necessary to perform bulk actions with total confidence.

Step 2: Configuring Targeted Filters

Once your data is fresh, the next phase is to build a multi-layered filter. In our example video, we look for a specific subset: users who have Jira access, but no Confluence access, and belong to a specific email domain. This level of granularity is what allows you to target contractor groups or specific departments without the need for external spreadsheets.

• Filter Criteria 1: We select “Included Apps” and set it to Jira. This isolates everyone who currently consumes a Jira seat.
• Filter Criteria 2: We use “Excluded Apps” to select Confluence. This narrows the list down to users who have Jira but lack Confluence access.
• Filter Criteria 3: We filter by the email domain, such as “azureadlab.resolution.de.” This ensures we are only targeting the specific external domain requested by the security or HR team.

By combining these three filters, we create a highly specific list of users. This is the moment to review the table for any surprises. Perhaps you notice a service account that shouldn’t have Jira access, or a user who should have had Confluence. This review phase is where you catch anomalies before they become permanent changes.

Step 3: Executing the Bulk Suspension Operation

After verifying the filtered list, we move to bulk operations. It is important to note that organization administrators are generally protected from these bulk actions; the system is designed so you don’t accidentally lock out the people who have the power to fix administrative mistakes. You can select all relevant users at once or pick specific individuals from your filtered results.

When you select “Suspend User” from the bulk action list, you must read the warnings like an engineer. This action is powerful: it ends active sessions immediately and invalidates API tokens and OAuth tokens. If these users have running automations or integrations, those workflows will cease to function the moment the bulk job completes. However, because suspension preserves user data and group memberships, you can rest easy knowing that reactivation will restore their previous access state perfectly if needed.

Step 4: Verification and Future-Proofing

Once the bulk operation finishes, we verify the results using the bulk results log. This log provides a clear audit trail of who started the job, whether it was successful, and exactly which users were affected. In our video, we confirm that the status of our targeted users has changed to “Suspended” directly within the User Browser interface. For ultimate peace of mind, we suggest a spot check by asking a suspended user to attempt a login; they should find it impossible to enter the system.

To make this process repeatable, we recommend saving your configured filter. This is incredibly useful for recurring tasks like quarterly offboarding or monthly security audits. You can even turn these saved filters into automated tasks that run without manual interaction. Finally, we advise creating a runbook in your company wiki and performing a “tabletop test” with a couple of test accounts to ensure your team understands the reactivation behavior and can handle future requests with the same speed and precision.

By following these steps, you ensure that your Atlassian environment remains secure and well-governed while reclaiming the time you would have otherwise spent on manual data entry.

We provide a comprehensive technical walkthrough to bridge the gap between background task execution and active incident management within your Atlassian ecosystem.

In our video, we walk you through the entire configuration process for setting up these automated alerts from start to finish.

https://youtu.be/aLO-Yr50EZU?si=qw9UCDUMNAVk1PdF

The Critical Importance of Trustworthy Automation

Automations are designed to save time and reduce manual overhead, but they are only truly effective if they are trustworthy. In many enterprise environments, administrators rely on “set-and-forget” tasks to handle vital processes such as user offboarding, governance routines, and license management. However, when these tasks quietly stop working, the consequences can be severe. You might find that license spend is creeping up because accounts aren’t being deactivated, or sensitive data remains accessible because an offboarding routine failed. If no one is manually checking the logs, these failures can go unnoticed for weeks, creating significant compliance risks and operational debt.

In our video, we emphasize that manual checking simply does not scale in a large organization. When you are managing hundreds or thousands of users, you cannot afford to wait for a manual audit to discover a problem. Instead, we must treat every task failure as a formal operational event. This means the system must be capable of detecting the failure, routing the information to the correct team, and tracking the resolution through a standardized workflow. Our goal is to ensure that you find out about a failure before your boss does, maintaining the integrity of your IT infrastructure.

Step 1: Configuring Jira Automation for Incoming Signals

The first step in building this failure notification system is to set up a Jira automation rule that can receive signals from external applications. You will need to navigate to your space settings and find the automation section. While you can build these rules at various levels, we recommend focusing on your IT Ops or Jira Service Management (JSM) project to ensure the right eyes are on the resulting tickets. To begin, create a new rule from scratch and select the “Incoming Webhook” as your trigger.

Setting the Trigger and Action

When you configure the incoming webhook trigger, Jira will eventually provide you with a unique URL and a secret key. However, these details are often only visible after the rule is saved and turned on. The next part of the process is defining the automation action. In our example, we choose to “Create a new work item.” For most organizations, setting the issue type to Problem or Incident is the best approach for tracking automation failures. This allows the failure to be prioritized alongside other technical issues in your queue.

Customizing the Work Item Details

It is essential to populate the work item criteria with useful information. For the summary, we suggest something clear like “Automated task failed.” In the description field, you should include actionable instructions or notes on where the administrator can find more specific details about the failure. One vital technical setting to remember is changing the work item criteria to “No work items from the webhook.” This ensures that the rule runs successfully without requiring an existing issue context, which is necessary since the failure is generating a brand-new ticket. Once these settings are finalized, turn on the rule to generate the necessary Webhook URL and Secret.

Step 2: Connecting the User Management App

With the Jira side of the integration ready, the next phase happens within our user management app. This app serves as the source of the automation tasks and is responsible for sending the “signal” when something goes wrong. Navigate to the settings menu and locate the section for Atlassian Automation Webhooks. This is where the bridge between the app and Jira is built. You can find the app on the Atlassian Marketplace if you haven’t installed it yet.

Registering the New Webhook

Click to create a new webhook and give it a highly descriptive name, such as “Automated Task Failed to Jira Problem.” A clear naming convention is critical for long-term governance and clarity, especially when multiple admins are managing the system. You will then need to paste the Webhook URL and the Secret that you generated in the previous step in Jira. It is important to treat this secret like a credential; do not share it or paste it into insecure locations, as it authorizes the communication between the two systems.

Selecting the Correct Trigger Event

The user management app supports several triggers, but for this specific workflow, you must select “Task Failure.” This ensures that the webhook only fires when an automated execution fails to complete. You also have the option to add notes to the webhook configuration, which we highly recommend for documentation purposes. Once you have toggled the webhook to “Active” and saved your changes, the link is established. For more technical details on this process, you can read the documentation provided by our team.

Step 3: Testing and Operational Verification

Configuration is only half the battle; verification is what guarantees the system will work when a real crisis occurs. Within the user management app settings, there is a run test feature specifically for the task failure trigger. When you click this, the app sends a test payload to the Jira URL you provided. You should receive immediate feedback from the app indicating whether the signal was sent successfully, but you must also verify the results within Jira itself.

Reviewing the Audit Log

The Audit Log in Jira Automation is your best friend when troubleshooting or confirming new rules. Check the log to see the event entry created by the webhook. The log will show you exactly what happened when the signal was received and should confirm that a new issue was created. If there are any errors in the field mapping or permissions, the audit log will highlight them here. This is a crucial step in ensuring that your IT operations are running as expected.

Confirming Ticket Creation

Finally, navigate to your issue queue or board. You should see a brand-new ticket titled “Automated task failed.” This confirms that the entire automation loop is closed. Now, instead of a task failing silently in the background, it is a trackable work item that can be assigned to a team member, prioritized, and fixed. By following these steps, you move from a reactive state to a proactive operational model, ensuring your automations remain a reliable asset rather than a hidden liability.

Best Practices for Ongoing Management

Once your webhook notifications are live, there are a few operational tips to keep in mind. Always revisit the automation audit log after making changes to your tasks or Jira workflows to ensure nothing has broken the connection. Furthermore, consider rooting different types of failures to different teams. While we showed a simple “create issue” action, Jira Automation is flexible enough to send real-time notifications to Slack, Microsoft Teams, or email simultaneously. This ensures the right team gets the alert in the platform they use most frequently, further reducing the mean time to resolution for automation failures.