Who can create Jira automation? A complete 2025 guide

Kenneth Pangan
Written by

Kenneth Pangan

Amogh Sarda
Reviewed by

Amogh Sarda

Last edited October 8, 2025

Expert Verified

Jira automation feels like a bit of magic, doesn’t it? It’s that handy tool that promises to take all the repetitive, manual tasks off your plate so your team can focus on what actually matters. But as soon as you decide to dive in, you hit the first big question: who can actually build these things? It’s a surprisingly common point of confusion, and the answer isn’t as simple as you might think.

This guide is here to clear all that up. We’ll break down exactly who can create Jira automation rules, explain the tricky parts of the permission system that trip most people up, and show you a much simpler way to handle those complex automations you’ve been dreaming of.

What is Jira automation?

In a nutshell, Jira’s native automation engine is a no-code tool that lets you build simple "if-this-then-that" rules to automate actions. Every rule you build is made up of three parts:

  • Triggers: This is the event that kicks everything off. For example, a rule could be triggered whenever a new issue is created.

  • Conditions: These are the specific criteria that need to be met for the rule to run. You could set a condition so the rule only applies if the issue’s priority is “High.”

  • Actions: This is the task you want the rule to perform, like sending a notification to a Slack channel or assigning the issue to a specific person.

Sounds easy enough, right? Well, for basic tasks, it is. But as you’ll see, this is where things start to get a little tricky, especially when it comes to permissions and the practical limits of what these rules can actually do.

Who can create Jira automation?

Let’s cut to the chase. Based on Atlassian’s official documentation, only a few specific roles can create rules. If you don’t have the right permissions, you won’t even see the automation settings in your project.

Global admins

If you have the "Administer Jira" global permission, you’re at the top of the food chain. You hold the keys to the entire automation kingdom and can do pretty much everything.

Specifically, you can:

  • Create and manage global rules that apply across your entire Jira instance.

  • Build multi-project rules that run across a specific selection of projects.

  • View, edit, and disable any automation rule, no matter who created it.

  • Decide whether Project Admins can create rules for their own projects.

Think of Global Admins as the ones who set the overall automation strategy and build the powerful, site-wide rules that keep everything running smoothly.

Project admins

Project Admins are the people you’ll most often find creating automation rules. Their power is limited to the specific projects they manage, which is a good thing, as it prevents them from accidentally messing up someone else’s workflow.

To create project-level rules, a user needs:

  • For company-managed projects: The "Administer Projects" and "Browse Projects" permissions.

  • For team-managed projects: The "Administrator" access level.

A common worry I see in community forums is the fear of giving someone too much power. The good news is that you can make someone a Project Admin for a single project without giving them Global Admin rights. This is a safe way to let team leads build the automations they need without risking changes to shared configurations like workflows or custom fields.

Regular users

For the most part, standard Jira users who don’t have any admin permissions are out of luck. They can’t create or edit automation rules.

There is one small exception: "recurring work automations." By default, a non-admin user can set up a rule to automatically clone an issue on a set schedule. However, a Global Admin can easily disable this feature, which means rule creation becomes a strictly admin-only affair.

Here’s a quick summary of who can do what:

RolePermission RequiredScope of RulesCan They Control Others’ Permissions?
Global Admin"Administer Jira" (Global)All Projects (Global & Multi-Project)Yes
Project Admin"Administer Projects" (Project)Single ProjectNo
Regular UserVaries (e.g., Edit permissions)Recurring work items onlyNo

The real challenge: Complicated permissions

Now you know who can create rules. But the bigger question is why this structure matters and how it can create some serious headaches in the real world.

The balancing act of power and risk

There’s a good reason Atlassian is so strict with these permissions. A poorly built automation rule can cause a lot of damage, from creating infinite loops that bog down your system to firing off thousands of notifications and disrupting workflows for entire departments. Restricting creation to admins is a sensible way to prevent things from getting out of hand.

The downside? It creates a bottleneck. If a support lead or a project manager has a great idea for a simple automation, they have to file a request with a Jira admin and wait. This slows down progress and puts an extra burden on your already busy admins.

Hidden complexity: The rule "actor"

Here’s a subtle but critical detail that trips up even experienced Jira users. When an automation rule runs, it doesn’t run as the user who triggered it. It runs as a special, built-in user called "Automation for Jira." This user has a specific project role called "atlassian-addons-project-access".

This becomes a problem when your workflows have security conditions. Let’s say you have a workflow transition that can only be performed by someone in the "Administrators" project role. If your automation rule tries to perform that transition, it will fail every single time, because the "Automation for Jira" user isn’t in that role. It’s a frustrating and often invisible failure point that leaves teams scratching their heads.

When "if-this-then-that" isn’t enough

Jira’s "if-this-then-that" model is great for simple tasks, but it starts to fall apart with more complex, real-world scenarios. Take this example from a

Reddit
Reddit user: they needed to create an Epic, then create 10 child Stories, and then link those Stories to each other in a specific, non-sequential order.

Trying to build this with native Jira automation is a nightmare. It often involves clunky workarounds like:

  • Chaining multiple rules: You have to create a series of rules where the first one creates the Epic, a second rule triggers off the Epic creation to create the Stories, and a third rule then tries to link them. This is fragile, difficult to debug, and a mess to maintain.

  • Using smart values and JQL: Pulling this off requires a deep understanding of Jira’s smart value syntax and advanced JQL, which is far beyond the skill set of the average project manager.

  • Hitting execution limits: Every single action and rule execution counts towards your monthly limit. A complex, multi-step process like this can burn through your allowance fast, which can lead to some surprising bills.

Pricing and execution limits

While Jira Automation comes built-in with every cloud plan, its usage isn’t unlimited. Atlassian tracks how many times your rules run each month, and the limits can be surprisingly low, especially for growing teams that rely heavily on automation.

Here are the current execution limits per the official Atlassian pricing page:

PlanMonthly Automation Rule Runs
Free100
Standard1,700
Premium1,000 per user per month (pooled)
EnterpriseUnlimited

The takeaway here is pretty clear. As your team scales and your automation needs become more sophisticated, you can easily hit these caps. When that happens, your workflows grind to a halt unless you’re ready to pay for a costly plan upgrade.

A simpler approach to complex automation

If you’re feeling constrained by Jira’s permission bottlenecks, technical complexity, and usage limits, you’re not alone. The native tool is a great starting point, but many teams eventually outgrow it. This is usually the point where they start looking for a tool that can grow with them, like eesel AI.

Empowering teams without admin rights

What if you didn’t have to stick to that rigid, admin-only model? With eesel AI, your support, IT, and ops leads can build, test, and deploy powerful AI agents without needing any special Jira permissions. Our platform is truly self-serve, meaning you can get started on your own in minutes. Connecting to tools like Jira Service Management, Zendesk, or Slack is a one-click process, not a month-long project requiring developer time.

Visual workflows without code

Tired of chaining rules and wrestling with JQL? eesel AI replaces that complexity with a simple prompt editor and a fully customizable workflow engine. You can easily define custom actions for your AI agent, like looking up customer order data from an external API or automatically creating a new Jira issue and populating it with the right information. These are tasks that are either impossible or incredibly difficult to achieve with native Jira automation.

eesel AI's visual workflow engine allows teams to build complex automations without code, simplifying the process for more people beyond just those who can create Jira automation rules.
eesel AI's visual workflow engine allows teams to build complex automations without code, simplifying the process for more people beyond just those who can create Jira automation rules.

Go beyond Jira with unified knowledge

Perhaps the biggest limitation of Jira automation is that it only knows about Jira. But real support and IT issues require context from everywhere. Your answers live in help articles, past tickets, internal wikis, and Google Docs.

eesel AI connects to all of them. It can learn from your knowledge base in Confluence, find procedures in Google Docs, and analyze thousands of your past support tickets to understand your brand voice and common solutions. It pulls all your scattered knowledge together to provide accurate, context-aware resolutions, something native Jira automation simply can’t do.

eesel AI unifies knowledge from multiple sources like Confluence and Google Docs, providing a richer context for automation than Jira's native tools can offer.
eesel AI unifies knowledge from multiple sources like Confluence and Google Docs, providing a richer context for automation than Jira's native tools can offer.

Automate smarter, not harder

So, who can create Jira automation? The short answer is Global Admins and Project Admins. But the real answer is more complicated. The system is designed for safety, but this often leads to bottlenecks, hidden technical issues, and limitations that prevent you from building the workflows you actually need.

Native Jira automation is perfect for simple, on-platform tasks. But when you need to handle complex logic, connect to external tools, or empower your frontline teams without making everyone an admin, it might be time to look for a better solution. eesel AI offers the power, flexibility, and intelligence to take your automation to the next level, without all the administrative overhead.

Ready to build powerful, cross-platform automations without the complexity? Try eesel AI free and see how quickly you can automate your support and ITSM workflows.

Frequently asked questions

Generally, regular users without administrative permissions cannot create or edit most automation rules. The one exception is "recurring work automations," but even this can be disabled by a Global Admin.

A Global Admin can create rules across the entire Jira instance or multiple projects, requiring "Administer Jira" global permission. A Project Admin’s power is limited to specific projects, needing "Administer Projects" or "Administrator" access depending on the project type.

Atlassian imposes strict permissions to prevent poorly built automation rules from causing system disruptions. This approach helps avoid issues like infinite loops, excessive notifications, or unintended changes across departments.

The primary challenge is the creation of bottlenecks. Team leads or project managers with automation ideas often have to submit requests to busy Jira admins, which slows down progress and increases the administrative burden.

Automation rules run as a special "Automation for Jira" user, not the person who triggered the event. If your workflow includes security conditions requiring specific project roles, the automation will fail if the "Automation for Jira" user is not part of that required role.

Tools like eesel AI empower non-admin users, such as support or ops leads, to build and deploy powerful AI agents without needing special Jira permissions. This provides a truly self-serve option for creating complex, cross-platform automations.

Share this post

Kenneth undefined

Article by

Kenneth Pangan

Writer and marketer for over ten years, Kenneth Pangan splits his time between history, politics, and art with plenty of interruptions from his dogs demanding attention.