I'm on Jira Cloud (xxxx.atlassian.net) and listed as an org admin. I want a Global Automation rule that runs when a project is created and adds our standard Epics, with Stories under each Epic. When I go to Jira Settings → System → Global automation, I don't see the "Create rule" option. * What permission or product role do I need to see "Create rule"? * Does a free or Standard plan limit global automation rules? * Is "Project created" plus a "Most recently created work item" branch with Parent set the right way to link the Stories to their Epics? Projects are mostly Team-managed Scrum, and we're moving to Company-managed.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can't see "Create rule" in Global Automation – need to auto-create Epics & Stories on new projects

BGajula

I'm on Jira Cloud (xxxx.atlassian.net) and listed as an org admin. I want a Global Automation rule that runs when a project is created and adds our standard Epics, with Stories under each Epic. When I go to Jira Settings → System → Global automation, I don't see the "Create rule" option.

What permission or product role do I need to see "Create rule"?
Does a free or Standard plan limit global automation rules?
Is "Project created" plus a "Most recently created work item" branch with Parent set the right way to link the Stories to their Epics?

Projects are mostly Team-managed Scrum, and we're moving to Company-managed.

Accepted answers

All comments

Matthew Sinclair

When you say project created - are you talking about a space? or atlassian "projects"?

But to the rest:

You need the Global automation permission (via group or other) in the Jira-Admin level access control panel
AFAIK the only limitation is the number of flows until Dec 3rd of 2026 - then its steps. Global is not a consideration last I checked.
Project - if this is an "Issue type" - then it will be created issue/work item and then you run if/then/else checks on type from there. If this is a "space" - you should use templates and then employ something like Deep Clone to clone issues in - as its very costly/messy to replicate work items/issues.

This covers a good chunk of that:

https://support.atlassian.com/cloud-automation/docs/permissions-required-for-jira-cloud-automation-rules/

https://www.atlassian.com/software/jira/pricing

I suggest you employ Rovo to assist in the minutia in how you approach the problem.

Caution - you will be metered on steps - global rules are potentially costly - measure carefully - plan it out - test.

You don't want this thing running amok and ending up non-functioning instance in automation terms.

BGajula

Thanks, that helps! It's a space. I've built a template space with the full hierarchy (Epics → Stories → Tasks → Sub-tasks), and I want to reuse that structure in every new space.

With Deep Clone, what's the best approach: clone the whole template space, or create the new space from a template and then bulk-clone the work items into it?
Can this be automated (for example, triggered when a new space is created), or does it have to be run manually each time?
Is the parent/child hierarchy (Epic → Story → Sub-task) kept when cloning?

Thanks for the help.

Trudy P Claspill

Hello @BGajula

Welcome to the Atlassian community.

Can you share a screen image of what you do see? Note that the button label is "Create flow" rather than "Create rule".

Screenshot 2026-11-03 at 12.42.45 PM.png

No Jira/JSM plan limits access to create Global Automation rules based on the plan itself as far as I know. The ability to create Global Automation Rules is limited by permissions. You must have the Administer Jira Global Permission to have access to and create Global Automation rules, as mentioned by @Matthew Sinclair .

Matthew Sinclair

Deep Clone is a Marketplace app - I don't work for them - but we use it in our org for this very reason.
We usually start with the space itself - cloning of issues with deep clone comes after - big fat warning however - sequential numbering of issue keys is not guaranteed. Worst case - epics go up first - then children. You can't clone issues in without a space for them to land on (Chicken or the egg syndrome). If your not going to use a market place app - you could engineer a bulk import via CSV pre-engineered to give you what you need (may be some limits) - or Jira Automation to "clone" one by one by one. Better yet - API something up via Rovo. Deep clone def. makes it easy.
Deep clone - yes - Automation will get action nodes (recently released in-fact) to help you get going. Manual isn't bad either.
Hierarchy is a global enforcement - there's no option to ignore. The only caveat is the said Issue/Work Types need to be present in the space. The real challenge is sequence of events - and linking of parent/child issues - not "relating."

You're encourage to test in sandbox before going to production - or an empty space to ensure you have your method down.

Again - careful with automation steps/metering.

Arkadiusz Wroblewski

Hi @BGajula ,

You could try Deep Clone's Space Clone to copy your template space and its work items, including the hierarchy.

However, automated cloning doesn't currently preserve the complete hierarchy, so the manual approach may be your best option.

Cheers,
Arek 🤠🧙‍♂️

Matthew Sinclair

Deep clone does - its the sequencing that gets funny funny at times.

Sami Shaik

@BGajula on the second question, the structure and the content are two different mechanisms, and that decides the approach.

The configuration comes from a template. Custom space templates capture Boards, Work types, Fields, Workflows, Roles, Notifications, Permissions, Shortcuts and Issue Security from a source space. They are available on all paid plans for team-managed spaces and on Enterprise for company-managed spaces, and yesterday’s Jira 2026 Autumn Release post says custom templates are now coming to all paid plans, rolling out over the next couple of weeks on the continuous release track. So your Epic, Story, Task, Sub-task hierarchy as work types travels with the template.

The work items do not. The same page lists what a template leaves out: “Apps, Automations, Work items from the source space, Enabled features, Feature settings.” A template will never give you the standard Epics and Stories themselves. That is where your automation idea is right.

The rule. Global automation, trigger Space created (“Flow will run when a space is created”), then a chain of Create work item actions: the Epic first, then each Story with its Parent set to the Epic just created. The smart value for that is {{createdIssue}}, which “accesses the previous issue created in the flow”, so {{createdIssue.key}} in the Parent field of the next action points at the Epic. For several Epics each with several Stories, create Epic A, its Stories, Epic B, its Stories, in that order, because {{createdIssue}} always means the most recent one. Keep the rule in Global automation, not in the template space, since automations are not copied either.

Deep Clone is the other route and it keeps hierarchy, but it is a manual action per new space unless you drive it from a rule; for a fixed starter set, native Create work item actions do the job with nothing to install.

One thing to test before you rely on it: the Parent field accepts {{createdIssue.key}} in the Create work item action in my experience with Story under Epic; I have not tested Sub-task under Task in the same chain. Run it once on a throwaway space.

Michał Krysiuk - Terano Apps

Hi @BGajula,

Trudy and Matthew covered the permissions: Administer Jira, and the button reads Create flow.

Sami laid out the native Space created rule well. One detail before you build it: {{createdIssue}} moves with every create, so after the first Story it points at that Story, not the Epic. Save the Epic's key with Create variable right after creating it and use that variable as Parent for each Story, then do the same for each Story's Sub-tasks. It works, but every item is its own action and a metered step, and every change to your standard means editing the rule.

I'm with Terano Apps, and we built Templify to keep a structure like yours as a template. I tested this setup on a fresh company-managed and a fresh team-managed space:

In your template space, open each standard Epic and choose Set as Issue Template on its Templify panel, with availability Global. Its Stories, Tasks and Sub-tasks come with it.
In your Space created rule, add Create issue from template once per Epic, with Target project set to {{project.key}} (not {{space.key}}, which came back empty in my test).

Space created rule with the Create issue from template action

What you get:

each Epic with its Stories, Tasks and their Sub-tasks created in the new space, parent links in place;
one action per Epic, counted as one step however many work items it holds;
the standard maintained in the template space, not in the rule.