---
title: "Integration with Appfire Configuration Manager for Jira"
canonical: "https://docs.getxray.app/space/XRAY/304349256/Integration%20with%20Appfire%20Configuration%20Manager%20for%20Jira"
format: markdown
---
> Macro (rw-ui-expands-macro)
>
> > Macro (rw-expand)
>
> > Macro (toc)
# Overview
Xray for Jira Data Center integrates with [Configuration Manager for Jira (CMJ)](https://marketplace.atlassian.com/apps/1211611/configuration-manager-for-jira-cmj), allowing you to include Xray configuration and Issue data in your CMJ snapshots. This helps you migrate, back up, or clone Xray projects more reliably across Jira instances.
## Snapshot Types
CMJ supports three snapshot types for Xray data:
| Snapshot Type | Includes |
| --- | --- |
| System Configuration | Global Xray settings |
| Project Configuration | Project-level Xray settings |
| Project Configuration with Issues | Xray project settings + Xray Issue data |
# Usage
## Integration Access and Snapshot Creation
If you have the CMJ integration already installed on your Jira DC instance, follow these steps:
> Macro (rw-ui-steps-macro)
>
> > Macro (rw-step)
>
> Click the gear/Administration icon (Figure 1 - 1) and then select Configuration Manager (Figure 2 - 1).
>
> The Configuration Snapshots screen will open (Figure 2).
>
> 
>
> > Macro (rw-step)
>
> In the Configuration Snapshots screen (Figure 2), click *Create Snapshot* (Figure 2 - 1).
>
> 
>
> > Macro (rw-step)
>
> The modal for the three Snaphots types creation will open (Figure 3).
>
> Select your desired Snapshot Type (Figure 3 - 1), fill the respective fields (Figure 3 - 2), and click *Create* (Figure 3 - 3) to proceed.
>
> 
>
> > Macro (rw-step)
>
> In this scenario, we will proceed with the generation of a *Project Configuration* Snapshot Type.
>
> You will see a message confirming the creation of the Snapshot (Figure 4 - 1).
>
> 
>
> > Macro (rw-step)
>
> If you click *Audit Log* (Figure 4 - 1), you will be taken to the Audit Log screen (Figure 5).
>
> Here (Figure 5) you can see and manage the audit log entries.
>
> 
>
> > Macro (rw-step)
>
> If you click *Done* (Figure 4 - 2), you will be taken to the Configuration Manager (Figure 6), where you will see your newly created Snashopt (Figure 6 - 1).
>
> 
>
> > Macro (rw-step)
>
> Here (Figure 6), you can:
>
> - Access the whole integration's capabilities (Figure 6 - 2).
> - Create more Snapshots (Figure 6 - 3).
> - After clicking the gear icon (Figure 6 - 4) corresponding to a Snapshot, then you can delete/download/recreate (Figure 6 - 4) that Snapshot.
## Installation
If don’t you have the CMJ integration already installed on your Jira DC instance, follow these steps:
> Macro (rw-ui-steps-macro)
>
> > Macro (rw-step)
>
> On your Jira DC instance, click the gear/Administration icon (Figure 7 - 1).
>
> 
>
> > Macro (rw-step)
>
> On the left side menu, click *Find new apps* (Figure 7 - 3).
>
> > Macro (rw-step)
>
> The Atlassian Marketplace Jira screen will open. Search for Configuration Manager for Jira (Figure 7 - 4) and you will see the integration below. Click *Free trial/ Buy now* (Figure 7 - 5) to install it.
# Snapshot Types
## System Configuration
A **System Configuration** snapshot (Figure 8) may include **Xray Global Configuration**.
Here (Figure 8), you can:
- Add the snapshot name (Figure 8 - 1; mandatory field).
- Enter a description/filters/boards/dashboards/global app data (Figure 8 - 2)
Once you’re finished, click *Next* (Figure 8 - 3) to preview, or *Create* to finish your snapshot generation.
If included, the snapshot can contain the following Xray components:
- [Miscellaneous Settings.](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUDDRAFT/pages/44838305)
- Custom Fields Settings.
- Enterprise Settings.
- [Issue Type Mapping Settings](https://getxraydocs.atlassian.net/wiki/spaces/XRAY/pages/301473147).
- Requirement Coverage Settings.
- [Default Column Layout Settings](https://getxraydocs.atlassian.net/wiki/spaces/XRAY/pages/301672631).
- Global Test/Precondition Types Data.
- Global Document Generator Templates.
- Test Status Configuration.
- Test Step Status Configuration.
- Global [Parameters Values](https://getxraydocs.atlassian.net/wiki/spaces/XRAY/pages/159712452) List.
- [Test Execution Archiving Configuration](https://getxraydocs.atlassian.net/wiki/spaces/XRAY/pages/301470346).
When deploying a snapshot created with System Configuration Type, this allows two deploy options:
- **Restore (Figure 9):** overwrites all target configuration with the snapshot (more below).
- **Merge (Figure 10):** attempts to combine the snapshot with existing settings (more below).
### Restore Mode
- Completely replaces the configuration in the target instance with the configuration from the source instance.
- All existing configurations in the target are overwritten.
Here (Figure 9), you can decide whether to restore everything or choose what to restore (Figure 9 - 1). Then, click *Next* to proceed (Figure 9 - 2).
### Merge Mode
Attempts to merge the source instance configuration into the existing target configuration.
Here (Figure 10), you can decide whether to merge everything or choose what to merge (Figure 10 - 1). Then, click *Next* to proceed (Figure 10 - 2).
For simple configuration fields, the merge logic is applied based on the configuration type:
- **Toggle-type settings** (left unchanged; the Target Instance configurations will prevail; Figure 11).
- **Multi-field settings**: settings from both source and target are **combined** - merged; Figure 12).
This logic will be applied specifically to these groups of Xray Settings, which contain **multi-field** settings:
- Miscellaneous Settings.
- Issue Type Mapping Settings.
- Requirement Coverage Settings.
- Default Column Layout Settings.
For more complex configuration fields, such as those listed below, the merging logic can vary depending on the configuration. The specific merging logic applied to each group is described here:
**Test/Pre-Condition Types **
- The CMJ app already creates these values since these are managed as
Jira Custom Fields.
- Xray will create/update/assert if the type is correct.
**Xray Global Document Generator Templates**
- If a template with the **same name and identical metadata** exists in the target instance, the template from the snapshot is not recreated in the target instance.
- If a template with the **same name but different metadata** exists:
- The system attempts to re-import the template, adding a prefix "`CMJ-`"** **to the name.
- If none of the previous conditions are met, the template is imported into the target instance.
> ℹ️ Templates installed from the Store on the source instance will be created as an **"Uploaded" **type in the target instance.
**Source**
**Target**
**After Merge**
**Xray Test Status Configuration**
- If there is no Test Status with the same name, it is created.
- If the test status **exists with matching fields **(Description, Final, Color, Requirement Status**)**, no action is taken.
- If the name matches but other fields differ, it will create the Test Status with the prefix "`CMJ-`" to avoid conflicts with the existing status in the target instance.
**Source**
**Target**
**After Merge**
**Xray Test Step Status Configuration**
Follows the same logic as **Test Status**:
- New if it doesn’t exist.
- Ignored if identical.
- The prefix "`CMJ-`" is added if a name collision occurs (while the other fields differ), and retries importing the field again.
> ℹ️ Test Step Status references a **Test Status** in its configuration. Special consideration is required during merging:
> ℹ️
> ℹ️ **Example (Between two different Instances):**
> ℹ️
> ℹ️ - **Source Instance A (Snapshot)**:
> ℹ️ - Test Status: TSA (type: OK).
> ℹ️ - Test Step Status: TSB, configured with TSA.
> ℹ️ - **Target Instance B**: Test Status: TSA (type: NOTRUN).
> ℹ️
> ℹ️ **Merge Behavior:**
> ℹ️
> ℹ️ - TSA in the source (type: OK) is different from TSA in the target (type: NOTRUN).
> ℹ️ - The Test Status is imported as **CMJ-TSA****.**
> ℹ️ - TSB should now reference **CMJ-TSA**, not the original TSA, to preserve consistency with the source configuration.
**Source**
**Target**
**After Merge**
### **Xray Global Parameter Values List**
- If a list with the **same name exists**: the options from the source list are **merged**, ensuring there are no duplicates.
- If **no list with the same name exists**: the list is imported with all its values.
**Source**
**Target**
**After Merge**
### **Xray Test Execution Archiving Configuration**
- Includes a **toggle** to enable/disable this configuration group.
- Merge logic:
| | | |
| --- | --- | --- |
| **Source Enabled ** | **Target Enabled** | **Result** |
| Yes | Yes | Project lists are merged |
| Yes | No | Source configuration overrides target |
| No | Yes | No changes made |
| No | No | No changes made |
## Project Configuration
A **Project Configuration** snapshot (Figure 25) may include the **Project Configurations**.
Here (Figure 25), you can:
- Add the snapshot name (Figure 25 - 1; mandatory field).
- Select the Project/s (Figure 25 - 2; mandatory field) and enable the option of including custom fields with value in at least one Issue.
- Insert a description and/or include project filters/boards (Figure 25 - 3).
Once you’re done, click *Next* (Figure 25 - 4) to proceed, or *Create *(Figure 25 - 4) to finish the snapshot generation.
The snapshot may contain these Xray Project components:
- [Project Miscellaneous Settings](https://getxraydocs.atlassian.net/wiki/spaces/XRAY/pages/301410073).
- [Project Default Column Layout Settings](https://getxraydocs.atlassian.net/wiki/spaces/XRAY/pages/301672631).
- Project Issue Type Mapping Settings.
- Project Defect Type Mapping Settings.
- Project Context Test/Pre-Condition Types Data.
- Project Test Step Custom Fields.
- Project Test Run Custom Fields.
- Project Parameter Values List.
- Project Remote Job Triggers Configurations.
- Project Document Generator Templates.
- Project [Test Repository](https://getxraydocs.atlassian.net/wiki/spaces/XRAY/pages/162299931) Structure.
- Project Requirement Coverage.
When deploying a snapshot created with the Project Configuration Type, this allows two deploy options: Merge and Restore.
### Restore Mode
- Completely replaces the project configuration in the **target instance** with the configuration from the **source instance**.
- All existing configurations in the target are overwritten.
Here (Figure 26) you can:
- Add a project name (Figure 26 - 1; mandatory field).
- Add a project key (Figure 26 - 2).
- Select whether to merge everything or choose what to merge (Figure 26 - 3).
Once you’re done, click *Next* to proceed (Figure 26 - 4).
### Merge Mode
Attempts to **merge** the source instance configuration into the existing target configuration.
Here (Figure 27), you can:
- Select the target project (Figure 27 - 1; optional field).
- Use the boxes to enable/disable the options to:
- Do not perform re-indexing during the deployment (Figure 27 - 2).
- Do not import Issue attachments (Figure 27 - 2).
- Add attachments (Figure 27 - 3; mandatory field).
- Choose wether to merge everything/choose what to merge (Figure 27 - 4).
Once you’ve finished, click *Next* (Figure 27 - 5) to proceed.
### **Xray Project Level Configurations**
For the following Xray configurations, which can be overridden at the Project level, the merge logic is applied:
- Project Miscellaneous Settings.
- Project Default Column Layout Settings.
- Project Issue Type Mapping Settings.
- Project Defect Type Mapping Settings.
Merge logic:
| | | |
| --- | --- | --- |
| **Source Enabled ** | **Target Enabled** | **Result** |
| Yes | Yes | Multi-Field Values are merged |
| Yes | No | Source configuration overrides target |
| No | Yes | No changes made |
| No | No | No changes made |
Xray Configurations covered:
- Project Document Generator Status.
- Project Requirement Coverage.
Merge logic:
| | | |
| --- | --- | --- |
| **Source Enabled/Contains ** | **Target Enabled/Contains** | **Result** |
| Yes | Yes | No changes |
| Yes | No | Enables/Add |
| No | Yes | No changes |
| No | No | No changes |
**Project Context Test/Pre-Condition Types**
- The CMJ app creates these values since these are managed as Jira Custom Fields.
- Xray will create/update/assert that the type is defined/correct.
**Project Test Step Custom Fields**
- Xray has a limit of six Test Steps custom fields. When that limit is reached, the remaining custom fields will not be created when deploying a project into the destination Jira.
- When a custom field already exists in the destination Jira with the same name, but not the same type, a new custom field will be created with a prefix "`CMJ-`".
- When the custom field already exists in the destination with the same metadata (except rank), it is considered the same.
- If it is a multivalue, the options will be concatenated.
**Source**
**Target**
**After Merge**
**Project Test Run Custom Fields**
- When deploying the project snapshot, the custom fields will be created in the order seen in the Project administration screen.
- Xray limits the total number of [Test Runs](https://getxraydocs.atlassian.net/wiki/spaces/XRAY/pages/301502714) custom fields to 12. When that limit is reached, any remaining Test Run custom fields will not be created when deploying a project into the destination Jira.
- When deploying a project with Test Run custom fields referencing a Test Type from another project not being deployed, the custom field will be created using that type, but it will appear strikethrough.
- When a custom field already exists in the destination Jira with the same name, but not the same type, a new custom field will be created with a prefix `CMJ-`.
- When the custom field already exists in the destination with the same metadata (except for the field *Rank*), it is considered the same.
- When the custom field has options, the options from the snapshot will be concatenated to the target instance options.
**Source**
**Target**
**After Merge**
**Xray Project Parameter Values List**
- This Project Parameter Values List configuration can have lists configured at the Global level that are imported to the project. When deploying from a snapshot, it is important to keep that logic.
- When Project Parameter Values List uses a Global Scope:
- If a list with the **same name exists**:
- The options from the source list are **merged**, ensuring that there are no duplicates.
- The Global List will be linked to the Merged Project.
- If no list with the same name exists:
- The list is imported with all its values.
- The Global List will be linked to the Merged Project.
- If the imported Project Parameter Values List uses a Project Scope:
- If a list with the **same name exists**: the options from the source list are **merged**, ensuring that there are no duplicates.
- If no list with the same name exists: the list is imported with all its values.
**Source**
**Target**
**After Merge**
**Xray Project Remote Jobs Trigger**
- When merging, an Active Configuration is overridden by any similar active configuration from the Source Instance.
- Given an imported configuration:
- If there is already a configuration with the same name and type, this configuration will be overridden by the one from the source instance.
- If there is no matching configuration, it will be created.
**Xray Global Document Generator Templates**
- If a template with the **same name and identical metadata** exists, no action is taken.
- If a template with the **same name but different metadata** exists: Xray attempts to re-import the template adding the prefix "`CMJ-`".
- If no matching template is found, the template is imported.
> ℹ️ Templates installed from the Store on the source instance will be created as an **"Uploaded" **type in the target instance. Validations are not executed (for store templates) since these have already been done on the source instance.
**Source**
**Target**
**After Merge**
**Xray Project Test Repository**
- If there is no Test Repository organization on the target instance, the Test Repository from the source instance will be re-created.
- If there is already a Test Repository organization, Xray will create the missing folders (the difference between the target structure and the imported structure).
- E.g: the snapshot/source instance Test Repository has the following structure:
Folder1
|_____ Folder2
- The Target Test Repository has the following structure:
Folder1
|_____ Folder3
- The resulting merged Test Repository will have the following structure:
Folder1
|_____ Folder2
|_____ Folder3
**Xray Project Requirement Coverage**
- Xray allows setting a Project with Requirement Coverage enabled.
- When importing, the Project Requirement Coverage Status will take the following behaviour:
| | | |
| --- | --- | --- |
| **Source Enabled ** | **Target Enabled** | **Result** |
| Yes | Yes | No changes |
| Yes | No | Enables |
| No | Yes | Disable |
| No | No | No changes |
# Project Configuration With Issues
A[ Project configuration with Issues snapshot](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/198247183) (Figure 43) can **only be deployed in Merge Mode**. This type of snapshot is **not allowed to be deployed in Restore Mode**.
Here (Figure 43), you can:
- Add a *Name* (Figure 43 - 1; mandatory field).
- Select a project/s (Figure 43 - 1; mandatory field).
- Select if/how you want to include Issues (Figure 43 - 4).
Once you’re done, click *Next* to proceed (Figure 43 - 5) and/or *Create* to finish the snapshot generation (Figure 43 - 5).
With this, you can merge a project configuration with an Issues snapshot into another project(s), or merge it into a new project/s (Figure 44).
Here (Figure 44), you can:
- Select the project/s (Figure 44 - 1).
- Decide whether to:
- Do not perform re-indexing during the deployment (Figure 44 - 2).
- Do not import Issue attachments (Figure 44 - 2).
- Add attachments (Figure 44 - 3; mandatory field).
- Decide whether to merge everything or select what to merge (Figure 44 - 4).
Once you’re finished, click *Next* (Figure 44 - 5).
Following CMJ base logic, there are some edge cases when deploying this snapshot type:
- Some or all of the matching projects on the target Jira instance do not contain Issues. In this case, all Issues and their data are imported into the empty projects on the target Jira instance.
- Some or all of the matching projects on the target Jira instance already contain Issues. In this case, if the same Issue exists both in the target project and in the snapshot, this Issue will not be imported. Issues not existing in the target project will be imported with all their data.
Consider these examples:
### Initial Setup
**Source Instance:**
- **Source Instance:**
- Project Key: EXA
- Issues: EXA-1, EXA-2, EXA-3
- **Deployment to Target Instance:**
- A project with the same key EXA is deployed to a separate target instance.
- After deployment, the Target Instance also contains:
- Project Key: EXA
- Issues: EXA-1, EXA-2, EXA-3 (identical to source at this point)
**Post-Deployment Changes:**
- **On the Source Instance, the following updates occur:**
- Existing Issues (EXA-1, EXA-2, EXA-3) are modified.
- A new Issue EXA-4 is created.
- **The Source Project now contains:**
- Issues: EXA-1, EXA-2, EXA-3 (all modified), and
**Snapshot Deployment:**
A snapshot is created from the updated Source Project and deployed to the existing EXA project on the Target Instance, using a merge strategy.
**Merge Behavior:**
- **Existing Issues (****EXA-1****, ****EXA-2****, ****EXA-3****):**
- Even though these Issues have been modified on the source, CMJ (Change Management Job) will not apply those changes to the target. The system does not overwrite existing Issues if their keys already exist, regardless of data differences.
- **New Issue (****EXA-4****):**
- Since this Issue does not exist in the target instance, it will be successfully imported during the merge.
- The newly imported Issue (EXA-4) will reflect the most current data from the source.
**This gets more complex when it relates to Issues links since:**
- The Issues linked to Issues of the project may not exist on the target instance where the snapshot has been deployed.
- The Issues linked to Issues of the project may exist on the target instance but under a different Issue key, as the user has the possibility to deploy a project to a different project key.
- There can be links between different Issues, but since CMJ doesn't update already existing Issues, it may not be possible to recreate these Issue links.
### **Issue Linking Across Multiple Projects**
Projects can often have cross-project Issue links - for example, Project A and Project B may include Issues that are linked to each other. How these links behave during deployment depends on how and when the snapshots are deployed.
**Deployment Scenario: Both Projects Deployed Together**
When snapshots of Project A and Project B are deployed simultaneously, CMJ can successfully create all Issues and maintain the links between them, even if the projects are deployed using different keys.
> ℹ️ Why it works: CMJ generates and uses a CMJ internal entity mapping during the deployment process, allowing it to resolve all Issue relationships across both projects, regardless of any changes in project keys.
**Deployment Scenario: Projects Deployed Separately**
When Project A and Project B are deployed via separate snapshot deployments, CMJ does not provide an internal entity mapping between the already deployed projects. To handle this, Xray attempts to resolve Issue mappings using a fallback strategy:
### **Xray Issue Mapping Strategy**
> Macro (rw-ui-steps-macro)
>
> > Macro (rw-step)
>
> **CMJ Issue Mapping: **checks if a CMJ mapping exists from a previous deployment (available if the projects were deployed together initially).
>
> > Macro (rw-step)
>
> **Issue ID Match: **tries to match using the internal Issue ID, Issue key, and Issue type.
>
> > Macro (rw-step)
>
> **Issue Key Match: **falls back to try matching by Issue key and Issue type.
>
> > Macro (rw-step)
>
> **Failure to Resolve: **if none of these methods result in a valid mapping, the Issue link will not be created.
### Deployment Examples
** Example 1: Projects Deployed with Same Keys**
- A snapshot of Project A is created and deployed using the same project key (Project A).
- A snapshot of Project B is created and deployed afterward, using the same or a custom project key.
- Issue links from Project B to Project A are likely to be preserved, as long as the linked Issues still meet the Issue Key matching logic (i.e., the target issues exist and are not modified during merge).
** Example 2: Projects Deployed with Different Keys**
**Project A is deployed under a different key, such as Project AA.**
- Project B is then deployed afterward with the same or a custom key.
**In this case, Issue links from Project B to Project AA may not be preserved, due to:**
- Inability to resolve Issue references via the fallback mapping steps described above.
### **Special Considerations for Xray Issue Types**
Given the complexity of deploying multiple projects and the behavior differences between various issue types, there are also some specific use cases related to Xray Issue Data that must be considered.
Below is a breakdown of specific Xray Issue Types and how they behave during snapshot deployment:
### **Tests**
No special considerations.
### **Test Sets**
No special considerations.
### **Pre-Conditions**
No special considerations.
### **Test Plans**
**1 - Dynamic vs. Static Test Plans**
- Xray supports Dynamic Test Plans (Enterprise feature) and *Static* Test Plans.
- If a Dynamic Test Plan is deployed to an instance where Xray Enterprise is not enabled, it will still be imported.
- However, it will be converted into a Static Test Plan, and all links to Tests will be preserved.
**2 - Test Plan Board Structure**
The logic for handling Test Plan Boards mirrors the behavior used in Test Repository Structure management:
- If the Test Plan Board does not exist on the target instance, it will be created entirely.
- If it already exists, only missing folders from the imported structure will be created to merge the two.
**Example:**
- The imported Test Plan Board has the following structure:
Folder1
|_____ Folder2
- The Target Test Plan Board has the following structure:
Folder1
|_____ Folder3
- The resulting merged Test Plan Board will have the following structure:
Folder1
|_____ Folder2
|_____ Folder3
### **Test Executions**
No special considerations.
### **Test Runs**
During deployment, if CMJ is unable to find the Test or Test Execution that the Test Run is linked to (i.e., mappings are missing), the Test Run will not be imported.
### **Attachments on Xray Issues**
- Xray Issues may include file attachments.
- When a snapshot is created, all attachments are exported into a directory located at:
`//Xray/cmjSnapshots/` (e.g.*, *`/Jira_Home/Xray/cmjSnapshots/6-30-2025 10.24AM`*)*
- **Same-instance Deployment: **no user action is required - attachments are automatically restored during deployment.
- **Cross-instance Deployment: **to successfully import attachments, the user must manually copy the related *cmjSnapshot* folder (for the specific snapshot being deployed) into the Jira Home Directory of the target instance.
# **Issues and Limitations**
Due to the nature of the integration relying on third-party support, there are certain limitations and known issues that are outside Xray’s control. Below are some edge cases that may cause unexpected behavior for users:
### **Test Run Custom Fields and Test Step Custom Fields**
Xray provides the capability to configure **Test Run Custom Fields** and **Test Step Custom Fields** at the project level. However, there are predefined limitations:
- A maximum of **six Test Step Custom Fields** can be defined (this includes native fields).
- A maximum of **12 Test Run Custom Fields** can be configured.
When deploying a snapshot into a project that already has custom fields configured, these limits can be exceeded. If the combined total of existing and incoming fields surpasses this limit, **some custom fields may not be imported**, leading to **potential data loss**.
Currently, CMJ does not support third-party apps to provide pre-flight checks or warnings during snapshot deployment. This means that if custom field limits are exceeded during the deployment process, **no warning or error will be displayed**, and the issue may go unnoticed until after deployment is complete.
### **Issues History **
All **Issue History** is maintained and managed on **Jira’s** end. During snapshot deployment, the migration of this history is handled entirely by the CMJ app.
However, CMJ’s implementation of this feature has known shortcomings, particularly when **project keys have changed** (Figure 45) between the source and target environments. In such cases, the migration process may not correctly update all references, potentially leading to a **mismatched Issue history **(Figure 45 - 1; 2; 3). This can result in references that **incorrectly point to** **old Issue keys** or even to Issues from the **original instance**, not present on the deployed instance.
E.g: Test Issue History (Figure 46 - 1).
The tag displayed will always display the "V2" Version (Figure 46 - 2).
### **Xray Configuration Changes Not Detected by CMJ**
There is **no known mechanism to notify CMJ** when Xray-specific settings have been modified.
For example, consider the following scenario:
- A snapshot of **Project A **is created and deployed.
- Xray Settings in the deployed project are modified.
- The original snapshot is then deployed again.
In this case, **CMJ will not detect any differences** and will display a message indicating that **no changes have been found**, even though Xray configurations were altered.
This behavior contrasts with how CMJ handles native Jira settings, such as **Issue Type Schemes**, where it correctly detects changes and includes them in the deployment process.
As a result, this limitation may lead to **Xray configuration changes being silently ignored**, posing a risk for environments that rely on consistent and trackable configuration deployment.
### **Xray Issue Type Name Mismatch Can Cause Context Overrides**
When deploying snapshots with **Xray-specific issue types**, ensure that the **Issue Type names in the snapshot match exactly** those in the target instance if you intend these ones to represent the same Issue Type.
If the names differ even slightly, CMJ will treat them as entirely new Issue Types. For example:
- The snapshot contains an Issue Type named *xTest*.
- The target instance uses the standard Xray Issue Type Test.
In this case, CMJ will **create a new Issue Type** (*xTest*) in the target instance and associate it with existing Xray custom field contexts (e.g., Test Type, Generic Test Definition, Cucumber Definition, etc.). At the same time, the original Test Issue Type will be **removed from these contexts**.
This can lead to significant misconfigurations in Xray, where custom fields are no longer correctly associated with the intended issue types. To avoid this, always ensure **strict name consistency** between the snapshot and the target instance for all Xray-related Issue Types.
### **Global Context Option Mismatch in the Test Type Custom Field**
When using a **global context** for the **Test Type** custom field in Xray, it is essential to ensure that the **available options are identical** in both the snapshot and the target instance.
If there is any mismatch, for example, if the snapshot does not include certain options that exist in the target environment, CMJ will treat the snapshot as the source of truth. As a result, **any options not present in the snapshot will be disabled** in the target instance after deployment.
This behavior can lead to unexpected outcomes, including missing or deactivated options in the **Test Type** field, which may affect Test execution, reporting, and overall usability within Xray.
To prevent this, always verify that the **Test Type field options are fully aligned** between the snapshot and the target environment when using a global context
**Document Generator Templates**
Templates installed from the [Template Store](https://store.getxporter.app/) on the source instance will be created as an **Uploaded** type in the target instance.
> Macro (rw-ui-expands-macro)
>
> > Macro (rw-expand)
>
> If you have questions or technical issues, please [contact the Support team via the Customer Portal (Jira service management)](https://jira.getxray.app/servicedesk/customer/portal/2/user/login?destination=portal%2F2%2Fcreate%2F28) or [send us a message using the in-app chat](https://getxraydocs.atlassian.net/wiki/spaces/XRAY/pages/301501383).