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.

[Trudy 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.

[Mallick_ Anik]

Hi @Trudy 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?

[Trudy 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 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.

[Mallick_ Anik]

Hi @Trudy Claspill 

Apologies for missing the question as I was waiting for an answer from user. To answer your question, yes, they can change it, but the only statuses they see are from HCOM, and not the statuses from CST, and the columns they want to move the items to have statuses from CST.

As for the screenshot, here it is.

They want to be able to move the items into Review L2, and the Post Remediation columns.

[Trudy Claspill]

Can you get a screen image of the board showing the issue they want to move? And a screen capture showing the error message the get when it fails to move?

Can you have the user provided you with screen images from one of the items that they cannot move to the specified column,  where the image shows that they can manually select the specified status directly in the item, and can complete the transition that way?

[Trudy Claspill]

Can you also share with us the JQL for the filter you are using as the basis for the board?

[Trudy Claspill]

If the board filter is pulling in issues form the CST and PRM spaces all the statuses for the workflows associated with the selected issues should be available for mapping to columns in the board. What I am trying to verify with my questions is:

The user can change the PRM item's status to Remediation and Post Remediation when viewing those items directly.

If the status can be changed manually in that manner for PRM issue #2 then PRM issue #2 in the board in the same status as PRM issue #1 should be able to move to the specified columns.

If the status is not available to select manually, then either the Status is not available in the workflow used by PRM or the transition between the starting status and destination status is not present in the workflow.

If the status is missing from the workflow, then yes the workflow would need to be changed. That change would affect every space that uses that workflow.

As advised by others you can make a copy of the workflows and workflow schemes from HCOM, modify those copies as needed, and then apply the new workflow scheme to just the PRM space. That would ensure other spaces are not affected.

However all boards that include PRM items would be affected.

[Mallick_ Anik]

I apologize but due to sensitivity of the data, I cannot provide exact screenshots.

To answer your questions,
whenever they try to move any item on the board, the specified columns show the same message:

As for statuses, they see the following statuses in the item:

The statuses mapped to the needed columns are 'Remediation', 'Post Remediation' and 'Everything Else' as shown in the previously shared screenshot.

The JQL is as follows:


I hope this answers your questions, and thank you very much!

[Mallick_ Anik]

Yes, as you said, the workflow that PRM uses, the one shared from HCOM, does not have the statuses needed. As such, user cannot even see the statuses in the dropdown.

I needed to confirm if there was a way I could only make changes to this board. I'm guessing that's not possible, and the least impact would be to make a copy?

What would be the impact on PRM if I did that?

Is the impact limited to:
1. Seeing the new statuses in every PRM board,

2. PRM won't sync to changes made to the HCOM workflow anymore

Is there anything I'm missing?

[Trudy Claspill]

Hello @Mallick_ Anik 

In order to enable PRM to use the statuses you mentioned that are not currently present in the workflow used by PRM, the statuses have to be added to a workflow used by PRM. That will affect every board where the PRM issues are included.

For other boards where PRM work items are included, those boards would have to be modified to map the new statuses to columns in the board. The new statuses will not automatically be mapped to columns. If the new statuses are not manually mapped, then PRM work items that are in those statuses will not display in those boards.

To reduce the impact you would need to make it so that PRM no longer shared the workflow used by HCOM.

In addition to the impacts you listed the following would be impacted.

Any filter that may include PRM work items in its results AND selects those work items based on the Status value of those work items.

Because filters could be affected, any reporting/dashboards that you have based on those filters could be affected.

If you are only adding the statuses to the workflow, not replacing statuses, that would minimize the impact to historical reports that include PRM work items. If you remove statuses that PRM currently uses, then you would have to specify what statuses are replacing those, and that could impact historical reporting.

Any automations that operate on PRM work items where the status of the work item is relevant could be affected.

If you have third party apps that enable you to do other sorts of customizations, like scripting or workflow enhancements, that interact with the PRM work items could be impacted.

An integrations or uses of the API to interact with PRM work items where the status of the PRM work items is relevant could be impacted.

That is not necessarily a complete list of everything that could be impacted.

[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. 

[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.

[Amit Singh]

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

[Amit Singh]

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 

[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!

[Amit Singh]

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:

1. Check the board column configuration and ensure all relevant statuses from the HCOM workflow are properly mapped to the desired columns.
2. Verify if the epic issue type in PRM actually has valid transitions to those statuses in the HCOM workflow.
3. If transitions are missing, you can add them in the workflow, but keep them minimal and non-disruptive (for example, adding global transitions).
4. 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 @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.

[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.

[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.