Duplicated field or section in a layout
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 will appear 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 the layout in Production (master branch)
- Create a User Story, 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, promote to the next environment.
- This deployment will fail with 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, the field 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 over the other 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 master branch and you commit the component in a new user story, it will be committed always like a new component instead of an update on the existing component.
You can also avoid this issue is some cases by moving back to the lower environment the user story where the component was committed the first time but never reached production and then commit again so that the existing feature branch, where the component already exist, is used instead of a new one created from master which doesn't contain the previous changes in that component.