Cannot add a child item to an epic

[Valerie Vliegen]

In a newly project (created with a kanban template) I cannot seem to add a child item (task,  story or bug) to an epic. I am able to create tasks in the project, just not as a child item to an epic. I cannot drag them to be a child to an epic either. 

When I try to add a child item to the epic, I receive the following pop-up: 

I am a space admin, and even an organization admin. 

I do not understand why I'm not able to do this, as I have a similar project where I am able to add child items to an epic.

This project uses the default software permission 'Default software scheme', the other project, where it's no problem uses another permission scheme, but I have checked and both of them have the same configuration. 

The epic has a status 'in progress', the task (if I'm trying to move it under an epic) has the same status. 

I did find this in the community; https://community.atlassian.com/forums/Jira-questions/Can-no-longer-create-assign-Child-tasks-to-Epics-August-6th-2025/qaq-p/3084973 but this doesn't seem to be the problem. 

The default assignee of the project is 'unassiged'. 

[Julien Morel]

Hi @Valerie Vliegen,

I would compare the two projects in one more place: the issue type setup / hierarchy for that specific project.

A few checks that often explain this when permissions look correct:

1. In the new project, confirm the child issue type you are trying to add is actually available in that project.

2. Open the child issue type layout and make sure the Parent field is available/editable, not just hidden on the view.

3. Try creating a brand-new child issue directly from inside the epic, instead of moving an existing issue under the epic. If the new one works but moving does not, look at workflow/status restrictions on the existing issue.

4. Compare the new project with the working project for issue types, not only the permission scheme.

The status being the same is useful to know, but the parent relationship is still saved as a field update, so field context/layout/workflow rules can block it even for an org admin.

[Ren Takahashi]

Hi @Valerie Vliegen, a few things I would check first because the answer can differ between team-managed and company-managed projects.

If this is a team-managed project, Jira's newer wording is usually parent/child rather than Epic Link. From the board or backlog, try opening the work item's More actions menu and look for Add parent or Change parent. You can also try dragging an existing work item onto the epic from the epic panel/backlog view if that panel is available.

If this is a company-managed kanban project, check whether the issue type hierarchy and screens are exposing the parent/epic field correctly. In some configurations, you can create tasks normally but not associate them to an epic from the place you are using because the field is hidden from that screen or the board view.

The quick checks I would make are:

1. Confirm whether the project is team-managed or company-managed.

2. Confirm the Epic issue type is the built-in/suggested Epic type, not a custom type named Epic.

3. Try assigning the parent from the backlog/board More actions menu instead of only from inside the issue.

4. If company-managed, ask a Jira admin to check the relevant screen/field configuration for the parent/epic field.

That should narrow down whether this is a project-type behavior or a field/screen configuration issue.

[James Gamble]

Hola Valerie,

This usually isn’t a permissions problem, even though the message makes it look like one.

In Jira Cloud, epic relationships now rely on the Parent field instead of the older Epic Link behavior. If that field isn’t on the issue screen (or can’t be edited in that project), Jira will throw a generic “you don’t have permission to update …” error when you try to add a child to an epic.

Atlassian covers this in their docs around the Epic → Parent field change.

I’d also double-check:

• The Parent field is included on the issue layout/screen for that issue type
• There’s no workflow rule (validator/condition) blocking edits in that status

There’s a good related breakdown here as well.

In most cases like this, it ends up being screen config or workflow restrictions rather than actual project permissions.

Thanks,

James