Will this be ever solved? Being able to opt out of re-creating custom fields should be readily available when importing a workflow. 

There's no workaround in the description, but it's possible to edit the export file and replace the relevant field IDs. You don't even need to access the database or use APIs, they can be checked in the Custom fields section of the (sys)admin panel by hovering over blue links or actions.

10 years since this was raised. This seriously hampers developing changes in another environment. Duplicate fields are the last thing you want. Why is it so hard to migrate project between Jira instances. The UI tooling is minimal, REST APIs are incomplete and then when there is a feature like this it turns out to be dangerous to use. 

I cannot overstate the amount of HOURS spent correcting custom fields after import, please save me 

+1 it hurts a lot, really. Created quite complicated wf on testing environment and after long testing and mending and all cannot import it to prod due to this error and will have to to recreate it from scratch manually... fields that Jira is trying to recreate exist with the same type, name and ID! doublechecked it. So really really bad.

I've observed when importing a workflow from another instance, if name, id and context are not an exact match, Jira creates a new field. This makes sence because Jira cannot make assumptions based just on field name. The example above is using newly created fields, exporting and importing into the same instance, so I think in that case a re-index after creating the fields may fix that. I haven't tested that.

However, and this is what the real problem is, when Jira creates new fields on workflow import, existing filters using the existing custom fields, switch over to the new fields and it breaks the filters. This behavour is the super buggy part.

It would be nice to have a field mapping screen on workflow import based on field names and the user could set mapping, even if id or context wasn't a match.

+1

Same problem here. It's difficult to clean up. Please fix this. 

+1

+1

+1

+1

+1

+1

+1

Any workaround?

We have the same problem. Importing a flowchart duplicate screens and custom fields.

Only 1/3 of the content from importing a workflow can be mapped to existing data. Workflow Statuses can be mapped but Screens and Custom Fields cannot. The workflow import functionality is less than half-baked and is over a 5 year old issue so it is doubtful this feature will ever been fully implemented. For now you must manually fix each and every duplicate Screen and Custom Field while importing the workflow. In some cases it is easier to recreate the Workflow using screenshots rather than import.

+1

This issue is impacting my team as well.

There is no point of using the Export/Import Workflow function if this problem is not being fixed. This would be a great help while waiting for the Export/Import Single Project requirement.
https://jira.atlassian.com/browse/JRASERVER-34307

We design/test workflows on a test server and then would like to import to our production server when ready without having to clean up the duplicate fields created.

We currently have a test environment that we encourage admins to use to create or modify projects and workflows. But it is seldom used because importing a workflow from the test server will create copies of custom fields, which are difficult to find and fix. Duplicated custom fields cause a number of significant problems, since users can't distinguish between the two custom field copies, hence filters don't work for unexplained reasons (note that Jira itself distinguishes between the custom fields, but that distinction is unavailable to users).

+1

We need to keep workflow versions archived for regulation compliance. Keeping them versioned via the name is getting to be problematic and we would like to archive the workflow versions off of JIRA, using a version control system, like BitBucket. We would also like to try out versions on a development system first (as others have mentioned above).

This issue is impacting us.

Not good idea just keep me an wheres my revenue

we are also facing same problem, while importing workflow custom field getting created once again.

This one is a no-brainer, surely. You'd think it would be the most obvious thing in the world that if the importer finds an existing field with the same name, that it would check that whether is the field you're targeting, rather than assuming you want to create the new field with the same name every time, especially if it's of the same type.

Same would apply to any screens that get referenced in the workflow tbh.

Unassigned and created by someone that is inactive.

The import workflow feature is useless while it creates custom fields. 

In my case I need to create and test on our Test server and get sign off from the customer.

When the customer signs off, I export form test server and import to production.

Every time I attempt to import I am presented with a long list of custom fields that the import process will "Create". These exact custom fields already exist in the production server resulting in duplicates EVERY TIME I IMPORT.

Get this assigned and fixed please!

Hello, there are no solution for this issue ??? for exemple directely in  database workflows descriptor ???

BR

After reading the previous comment carefully, and trying it, it seems that there is a simple workaround - export (and then import) as XML. I'd like to humbly suggest that the workaround be prominently featured in the description.

It was not at all clear to me that the expected method for exporting and importing a workflow from one JIRA instance to another JIRA instance is to AVOID the option to export/import as a workflow but instead to export as an XML file, then edit the file, select-all, copy, and then paste the XML into the text window for importing XML into the other JIRA instance. It may be just me, but that wasn't obvious to me at first glance. It appears to have worked - at least once - so far.

I think this problem only applies to the workflow exporter, not the Export as XML workflow export. Given the consequences of using this, I can see how anyone can say that it works as designed! I think the importer should check if custom fields of the same names already exist, warn the admin and ask what to do - create or reuse.

This makes the workflow import useless. So we cannot develop a workflow in a staging environment, test, export and then import into production.

In our case we require workflow changes (and indeed all changes of substance) to be developed in "dev", installed into the staging area "stage", and then, if approved for it, moved into production "prod".

So my options are

1. Make the changes to the workflow in "dev", export from "dev" and import into "stage" (or "prod"), which causes 14 fields to be duplicated, along with three screens? Then go by hand and move/delete fields/screens to fix that the import broke? All while users are actively using the production system?
2. Make the changes to the workflow in "dev", recording the actions as we go, then repeat those same actions in the "stage" and "prod" environments, hoping that human error does not cause any discrepancies.

SUGGESTION
It seems to me that this could be FIXED by using the same type of logic used for mapping the Status' while importing a workflow. Allow the user to match them (or create new fields) after the automation has best-guessed the match. Since this already happens for "Status Mapping" it seems like a no-brainer that this could happen to avoid creating duplicate and erroneous fields.

Just my 2 cents.

-Vik

I just got bit by this issue - users asking why there query did not return correct results. Turns out the pick the duplicate field which had no data. At very least should be very clear warning that field will be duplicated.

Gotta say, I'd rather it not import duplicates ever. So skipping them would be preferable from my point of view.

A mapping screen would be most preferential but I realize that mapping fields/types/values etc might be painful.

Importing duplicate screens and custom fields make this a fairly useless functionality fr a consultant point of view, seems easier to build by hand from scratch and ignore the trouble.

I don't really understand why fields and workflows have to be tied in together. Is it because some workflows have transition screens?
Sometimes the are fields associated to validators/conditions/post-functions, but does are not the only fields being created at the time of an import.

Anyhow, if this is by design, there is something I don't understand about the usage of a "dev vs prod" JIRA.

In order to keep our production JIRA stable, we require people to experiment in our test instance before doing any change to the production instance. What we do is regularly update the test instance with a copy of the prod JIRA database, so the two systems are nearly identical.
When we developed new workflows and tried to import them in the prod instance, this created *dozens *of duplicate fields (I'm not exaggerating). The behavior of JIRA when deleting fields is very painful (you can only delete fields one at a time and the page reloads after each deletion) so it's a tedious task. Also, some statuses and screens are duplicated if I'm not mistaken.

This is very frustrating since both instances shared the same fields of the same type with the same ID and the same configuration.
We are now obligated to develop directly on the production server, but we are much more restrictive on the number of admins in the production instance.

You could at least have an option to "Not export anything" and let the import process do a best effort to match things.

We encounter the same problem: we want to migrate a project from one JIRA instance to a new JIRA instance according to what is described at: https://confluence.atlassian.com/display/JIRA/Restoring+a+Project+from+Backup#RestoringaProjectfromBackup-pluginversionmismatch.
This particular project uses 3 workflows. After import of the workflows in the new JIRA instance, the same custom fields are imported 2 or 3 times (depending on the usage in the workflows and screens), the same screens are created 2 or 3 times, which leaves us with a lot of work to remove all those duplicated screens and fields. Whether this is by design or not, migrating a single project from one instance to another JIRA instance already costs too much manual steps and labour, and this makes it even worse.

The code doesn't try to map custom fields, it just creates them (because you can have >=2 custom fields of the same name). This is working as designed/implemented. This mapping would be a feature request. This feature is more complicated than it looks. For example:

• What happens if the options in the import don't match those in the existing custom field.
• What happens if the existing custom field is not visible in any projects already.
• ...

In the end we would have to implement some custom field mapping screen just like we do with statuses.

Interesting one. Hard to say if this is by design or accident. An import (i'm guessing) just creates the fields and they get assigned a new id hence to the 'system' they are unique.
If we built in a check to not create custom fields based on name alone (even type too), then we could potentially run in to problems where a custom field already exists that is totally unrelated to the workflow and then we don't create the appropriate one because something named the same already exists.

To me, this mostly sounds like we need to update the docs and leave it as is.
Thoughts bbain, rtekhov ?

Hi mhenderson / jdevenny,

What do you reckon the behaviour should be in the use case mentioned in the description? Thanks guys.

Cheers,
Os.