--- title: "Duplicate custom fields" canonical: "https://support.appfire.com/space/CMJ/198181755/Duplicate%20custom%20fields" format: markdown --- > Macro (aura-html) ### The problem Configuration Manager for Jira (CMJ) uses a custom field's name and type to get a match between fields in a snapshot and a target system. However, since you can have multiple custom fields with the same name and type on a single Jira instance, it isn't always possible to match all fields correctly. In such cases, CMJ relies on the order of the fields to find a match. Yet, this approach isn't always reliable when there is ambiguity. Deploying a snapshot when fields are not matched correctly can likely lead to [data loss](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/197923030). ### Solutions CMJ allows you to [resolve custom field conflicts ](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/198116696)and avoid the aforementioned data loss. It provides you with a UI that lets you manually map your custom fields in cases where multiple fields with the same name and type exist. This feature can also provide pre-matching if the fields have the same native IDs. ![image](media://8acbff01-1868-499d-82c7-0c91ed1e43c3) If you're using the [REST API](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/197955929) for deployment and such a case is detected, by default the deployment will stop and an error message will pop up. In this case: - If you want to perform the deployment anyway, the error severity can be reduced to a warning with the same message which won't stop the deployment. For this purpose, you need to enable the "Stop deployment in case of possible data loss" option in CMJ’s [General Settings](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/198214114). - The duplicate fields on the source Jira can be temporarily renamed before creating the snapshot. Likewise, the duplicate fields on the target instance can be renamed before deployment to get a proper match.