This usually happens when form sections already exist in the target instance and the update set brings them over again, causing duplicates.
A few things I see you can check and fix:
Form Section records
Go to sys_ui_section on the target (test) instance.
Check if the duplicated sections already existed before the update set was committed.
If yes, you can safely delete the duplicate sections (keep the one tied to the correct view).
Update Set contents
Open the update set and look for multiple Form Section sys_ui_section and Form Element sys_ui_element records for the same table view.
This often happens when the same form was modified multiple times or by multiple developers.
Remove unnecessary or duplicate records before committing.
Views
Make sure the View name is consistent between source and target.
If the view exists in target with a different sys_id, ServiceNow may create a duplicate section during commit.
Best practice I see going forward
Avoid creating new views unless needed.
When working on forms, have one update set per form change.
Before committing, always preview update set changes to catch duplicate UI records.
If possible, baseline the form in lower environments so sections already exist before committing changes.
At end of day, this is a common UI metadata issue, not a platform bug. Cleaning up duplicate sys_ui_section records and tightening update-set discipline usually resolves it.
Hope this helps my Friend!
@apurva3 - Please mark Accepted Solution and a Thumbs Up if you find Helpful!!
