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; } } }

Cannot move Epics from a column to certain others due to workflow configuration

Mallick_ Anik

As a JIRA admin, I have received an issue where someone could not move an epic to a certain few columns in their board.

The workflow for this space (CST) has all the necessary statuses in the workflow.

The board that has this issue pulls items from a different space (PRM).

PRM uses the workflow scheme for another space (HCOM).

My question is how am I supposed to make the columns work without making any visible changes to the other spaces. Any advice is appreciated.

Thank you.

Accepted answers

All comments

Mikael Sandberg

Hi @Mallick_ Anik,

Welcome to Atlassian Community!

A couple of questions, are all the statuses that both spaces are using linked to a column on the board? The user that had the issue, do they have the right access to both projects? If all the statuses are linked to columns then you have to start looking at the permissions.

Trudy P Claspill

Hello @Mallick_ Anik

Welcome to the Atlassian community.

When you say the PRM space uses the workflow scheme for another space, that is irrelevant. It doesn't matter that a space within the scope of the Board shares workflows with other spaces.

What happens when the user tries to move the Epic to another column?

What are the types of each of the Spaces in this scenario?

Team managed or Company managed
Business, Software, or Service

Is this for a Scrum board or a Kanban board?

Have you checked the Column mapping to ensure that all statuses are actually mapped to columns, and none are in the Unmapped Statuses area?

If your board is mixing issues from both Team Managed and Company Managed spaces, even if the workflows use Statuses that share names in the backend the statuses in Team Managed spaces are considered unique. So you need to make sure all statuses are mapped to the columns, even if the status names appear to be the same.

Another thing to consider is can the user able to change the status of the Epic directly within the Epic, rather than trying to move it to a different column on the board? If they cannot, then they don't have sufficient permissions in the space in which the Epic exists, and that needs to be addressed. If they can change the Epic status directly, then I suspect that the problem is the Columns mapping.

Artem Taranenko

I would check the workflow and the permissions

Workflow:

Check whether a transition exists between the current status and the target status for that issue's workflow. Columns may be configured on the board, but an issue can only move between statuses if a corresponding workflow transition is defined. For example, in a linear workflow (To Do → In Progress → Done), you cannot move an issue directly from To Do to Done unless a transition between those statuses exists. You'd have to move it along a valid transition path: To do → In Progress, In Progress → Done.

Permissions:

User needs Browse and Transition permission in both projects.

The fact that they see issues tells me they have Browse, but likely are lacking the Transition Issues permission in one or both projects.

My advice is to also check the groups the user is in and see if it makes sense to give that permission to the group, or maybe add that user to a role that has that permission. Giving permission to individual user is essentially making an exception rather than approaching the issue systemically.

Amit Singh_ird2k6

This issue is most likely related to the workflow and board column mapping across different projects/spaces.

Since your board is pulling items from the PRM space, and PRM is using the workflow scheme from HCOM, the statuses available for movement are controlled by that workflow, not CST.

Even if CST has all the required statuses, they won’t apply unless PRM issues follow the same workflow.

To resolve this without making visible changes to other spaces, you can:

Check the board column configuration and ensure all relevant statuses from the HCOM workflow are properly mapped to the desired columns.
Verify if the epic issue type in PRM actually has valid transitions to those statuses in the HCOM workflow.
If transitions are missing, you can add them in the workflow, but keep them minimal and non-disruptive (for example, adding global transitions).
Alternatively, create a separate board filter or board configuration that only maps the allowed statuses correctly, without modifying the underlying workflow.

In short, the movement issue is not a board problem but a workflow transition limitation from the source project (PRM/HCOM). The cleanest approach is to adjust mappings or transitions without impacting existing behavior.

Let me know if you’d like help checking the transitions or board settings.

Mallick_ Anik

Hi @Trudy P Claspill

Thank you for your response.

When the Epic is being moved to certain columns, it shows that the epic cannot be moved into that column because of workflow configurations or permissions.

They are all company managed and the board is a Kanban board.

I have identified the issue, it's that the workflow used for HCOM which is used by PRM does not have the statuses for the columns present.
The specific statuses are present in the workflow of CST itself.

Adding the statuses to the HCOM workflow will add them as options to all other boards as well, correct? That is something I am trying to avoid. Is there any better alternative?

Mallick_ Anik

Hi @Mikael Sandberg
Thank you for your response.

The statuses are linked. The issue I have identified is in the workflow for HCOM itself.
The workflow for CST has all the statuses with their appropriate transitions mapped, but workflow for HCOM does not have the statuses for the specific columns we are trying to move the epic to.

Would you have any advice for how to make changes so that only the current board that has this issue will be affected?

Thank you.

Mallick_ Anik

Hi @Amit Singh

Thank you for the response.

You are absolutely correct. The statuses for the specified columns are not present in the workflow for HCOM but present in CST.

I have had the idea of adding the statuses to the workflow for HCOM, but that will result in the new statuses showing up for all the boards in HCOM and PRM, correct? That is something I'm trying to avoid.

Is there any alternative I can implement? Thank you.

Mallick_ Anik

Hi @Artem Taranenko

Thank you for your response.

You are correct in assuming the statuses weren't mapped. As described in the previous responses, CST has the correct statuses mapped in the workflow, whereas HCOM does not have the statuses at all.

As such, I am looking for a way to make it so only the specified board in CST is affected by my changes, and nothing else.

Trudy P Claspill

No that doesn't sound correct and shouldn't be needed.

Please share a screenshot from the Board settings > Layout > Columns page showing the mapping of statuses to columns.

Also please answer the question about whether the user can change the status of the Epic directly by clicking the status button when viewing the Epic details

Trudy P Claspill

You should not add statuses to the HCOM/PRM workflow to match the column names in your board. The statuses should already be available to map to the existing columns, or you can add additional columns to match the statuses from HCOM/PRM.

Amit Singh_ird2k6

Hi Mallick_ Anik,

Thanks for clarifying. Based on your description, the main points are:

1. Workflow transitions: Even if columns are mapped on a board, an issue can only move between statuses if a workflow transition exists. For HCOM, the required statuses and transitions are missing, which is why issues cannot move.

2. Permissions: Make sure the user has Browse and Transition Issues permissions in both projects. If they can see issues but cannot transition them, it’s likely a permission issue. Check the user’s groups or roles—granting permissions at the group/role level is better than to an individual user.

3. Board-specific effect: To make changes affect only the CST board without impacting HCOM, the safest approach is:

Create a board-specific workflow for CST that includes the needed statuses and transitions.

This way, HCOM’s workflow remains unchanged.

Essentially, you cannot isolate statuses in a single board without creating a separate workflow or adjusting board-specific column mappings.

Let me know if you want me to outline the exact steps to implement a board-specific workflow for CST.

Best regards,

Amit Singh

Amit Singh_ird2k6

Hi Mallick_ Anik,

Thanks for the details. Based on your description:

Issue source vs board space: The problem arises because the board is pulling items from PRM, which uses the HCOM workflow. Even though CST has all required statuses, PRM’s workflow does not include the necessary statuses for those columns.

Board-specific solution: To make columns work on this board without affecting other spaces, the safest approach is to create a board-specific workflow scheme for PRM:

Clone the HCOM workflow and add the required statuses and transitions for this board.

Associate the cloned workflow only with the PRM project or issue types used on this board.

This ensures that HCOM and other projects remain unaffected.

Alternative: If creating a separate workflow is not feasible, you could also explore board column mappings, but keep in mind that an issue can only move between statuses if the corresponding workflow transition exists. Without adding transitions or statuses in the workflow used by PRM, the issues cannot move.

Essentially, to isolate changes to this board, you need either a dedicated workflow for PRM or carefully mapped transitions that do not impact other projects.

Let me know if you want me to outline the exact steps to implement a board-specific workflow for PRM.

Best regards,

Amit Singh

Mallick_ Anik

Hi @Amit Singh

Thank you for your detailed answer.

Steps on getting the board-specific workflow that won't affect PRM or HCOM would be a huge help, thank you!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud