Bulk transfering from Jira Software boards missing custom fields

[Rodrigo Cunha]

Hi all,

My teams manage our customer feedback with other parts of the business through a specific issue type called Feature Request, which we now want to transfer to JPD as part of our new product discovery process.

We have a custom field (Customer Votes, as a Number) that is critical to our prioritization (our customer support teams give a "+1" every time new feedback related to the same request comes up).

I'm trying to move these issues to JPD by bulk moving, but although I created a new custom field on JPD with the same type and name, the process is completely ignoring it.

Am I missing something? Is this actually possible?

If not through the initial bulk move, is there a way to make it a two-step process? For example, a bulk changes process in JPD based on a CSV with all the voting information (e.g., from the export of my board).

I considered using CSV import instead of bulk to fix this, but it causes so many more issues that I'm steering away.

This is becoming a big blocker to adoption as some teams have 200+ feedback issues, so it would be a massive effort to change each vote manually.

Any ideas?

[Stephen_Lugton · Accepted solution]

@Rodrigo Cunha I haven't tried this to see if it'll work, but you can now add global fields from Jira to JPD, try adding your custom field as a global field to JPD

[Rodrigo Cunha]

Hey Stephen!

I haven't tried global fields yet, but maybe because I completely misunderstood the concept - I thought that it was about fields between multiple Discovery Projects instead of Jira and Discovery projects (also, when I started looking at this, global fields were not available, so probably my brain was stuck on the old way).

I will definitely give it a try! Thanks for the suggestion mate!

[Rodrigo Cunha]

Worked as a charm @Stephen_Lugton!

Thanks for the suggestion!

[Hermance NDounga]

Hey Rodrigo, 

I am missing three informations to make sure i grasp the situation : 

1. You mentioned your current process is done through an issue type, but is it coming from Jira Software, Jira Service Management, or Jira Work Management? Is it inside a company-managed project or a team-managed project? 

2. Did you create a new global field or just a new field in the project ? 

3. you said the process is "ignoring it": is it because when you bulk move, you don't even see the field and cannot map it, or it's because during the process, you see both fields, you map one to the other but this is ignored and in the end, you get blank value? 

Thanks 

[Rodrigo Cunha]

Thank you for your questions, Hermance:

1 - Jira Software and it's a company-managed project

2 - Project field

3 - Sorry, I should have been clearer about the meaning of "ignoring" - it's the value that is ignored even though I selected "retain" in the field selection. So yes, I do see the field in the step 3, but the value comes empty.

Thank you again, and I hope that the above can help with the diagnosis!

[Rodrigo Cunha]

Hey Hermance,

I'm happy to announce that @Stephen_Lugton answer worked for me. Just found the global field in the Jira fields and then added and it started working.

As I said to Stephen, I misunderstood the concept of the global field - I thought it was for fields between JPD boards instead of an "all Jira" field.

My two cents: One feature that would help customers migrate existing issues would be a way to identify, during the bulk move process, which fields are being "lost" and which could be transformed into global fields.

I imagine this might not be easy as it's a JIRA feature and not fully in control of your team in JPD, but I can see value even between other types of issue migrations (JSM to JS, etc).

Thank you again for your support.

[Hermance NDounga]

Super happy that the suggestion from @Stephen_Lugton worked! that's also what I was hinting at with my second question ;) 

As you said, the bulk move panel is outside our scope, and also, you were in a bit of an unusual case because you were going from company-managed to team-managed, which the move with the least "expected" results (I mean moving from company-managed to company-managed or from team-managed to team-manged is better handled). 

One thing that is in our control however is to improve the way we communicated about global fields, and make sure all users understand how they work, so I'll keep a note on that and bring it to my team. 

Have a nice day 

Hermance