Error [Layout XXXXX] Field: field, value:XXXXXXXX appears more than once
When deploying page layouts with Copado, you might receive the error below:
"Error [Layout XXXXX] Field: field, value:XXXXXXXX appears more than once".
This error appears when the promotion branch that is being deployed contains duplicate fields in the xml file of the layout.
This is an example of how this error can be reproduced:
- In the source org, add a field to a page layout that is not present in the layout in production (master branch).
- Create a user story and promote and deploy the page layout to the next environment.
- In the source org, change the section of the field in the page layout.
- Create a second user story and promote it to the next environment.
- This deployment will fail with the error "[Layout XXXXX] Field: field, value:XXXXXXXX appears more than once".
- If you check the promotion branch of the second deployment, you will notice that the field appears twice in different sections.
This is the standard behavior of Git. Since the field is not included in the master branch, it will not be present in the feature branch when committing in the user story, and therefore, the field is always added in the user story in different sections instead of being removed from the previous section and added to the new one.
When merging the feature branch into the promotion branch, Git is not able to determine which field location will prevail because the feature branch doesn't contain the deletion of the previous location, and therefore, Git creates a duplicate field in the promotion branch.
How to Address This Issue
You will have to remove the duplicate field from the promotion branch of the user story that you want to keep. Once the promotion branch is cleared, you can go ahead and launch the deployment.
How to Avoid This Issue in the Future
When committing components in user stories, if you are updating an existing component make sure the changes are applied in the feature branch. If the component never reached the master branch, and you commit the component in a new user story, it will be committed always as a new component instead of as an update to the existing component.
You can also avoid this issue in some cases by back promoting to the lower environment the user story where the component was committed the first time but never reached production and then committing again. In this way, the existing feature, branch where the component already exists, will be used instead of a new feature branch created from master, which doesn't contain the previous changes in that component.