Documentation for the Atlassian Marketplace app.
The app adds a Config Analyzer page to the settings of any Jira Cloud project. From there you can:
It is read-only: it requests read scopes only and never modifies your configuration.
Open a Jira project → Project settings → in the left menu, under Apps, select Config Analyzer.
Press Analyze project. The app reads the instance configuration and produces a Word document containing:
Note on large instances. To know which schemes are shared, the app has to scan the projects of the instance: there is no endpoint that answers “which projects use scheme X”. The scan runs in batches and shows progress. On an instance with hundreds of projects it takes a while; it is not stuck.
Press Custom fields (CSV). You get a CSV with three columns:
| column | meaning |
|---|---|
id |
the field id, e.g. customfield_10050 |
name |
the field name |
source |
screen, workflow, or screen+workflow |
source tells you where the field was found: on a screen used by the project,
referenced by a workflow rule, or both.
Limitation to be aware of. Fields referenced inside an app script by name instead of by id cannot be detected — there is no id to extract. Fields referenced by id are found.
In your Data Center instance: Administration → Issues → Workflows, find the workflow, and use the export as XML action. Save the file.
The app never connects to your Data Center instance. You export the file yourself and upload it; it is parsed locally in your browser and is not sent anywhere.
Workflows left without an XML are not included in the document.
The comparison is deterministic. It reports what is in the two files and marks anything it cannot prove as to verify, showing the raw values side by side. It never guesses a cause and never pairs items that do not match exactly.
| result | meaning |
|---|---|
| OK | present on both sides, matching |
| INFO | a difference that is expected, e.g. a different status id (ids are regenerated by the migration) |
| TO VERIFY | no exact match — look at it yourself |
| MISSING IN CLOUD | present in Data Center, not found in Cloud |
| EXTRA IN CLOUD | present in Cloud, not found in Data Center |
| STANDARD | standard OSWorkflow post-function, handled internally by Cloud — not a gap |
Rules are matched by canonical identity. The same rule is often named differently in the two worlds — a ScriptRunner script, a JSU function, a role condition. The app maps the known equivalences so that one rule counts as one, instead of appearing as one “missing” plus one “extra”. Equivalences that are not confirmed are left as to verify rather than guessed.
A MISSING and an EXTRA on the same transition usually mean the same rule under two names. If you find such a pair and confirm they are the same rule, report it to support and the equivalence will be added.
If the uploaded XML does not look like the workflow it was assigned to, the app says so before generating the document, and shows how many transition ids the two sides have in common. Transition ids are preserved by migration, so no ids in common is a strong sign the files are different workflows. Nothing is blocked: you confirm or upload again.
Note that the workflow name often differs legitimately after a migration, so a different name alone is not a problem — what matters is the structure.
Interface and generated documents are available in English and Italian. Switch language from the bottom of the panel; the choice is remembered.
See the privacy policy for details.
Questions, bug reports, or a rule equivalence to add: official.fdnf@gmail.com