Workflow import/export is not currently available in Cloud

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.