Domain Separation

[Manny11]

Hello, 

 We are currently experiencing a similar issue, when customer updates are imported into the instance via update set Form Sections get duplicated. We are using Domian Separation, and I believe this is part of the issue.

When we load update sets via Global Domain, some customer updates are in a different domain "Domain X". Can this cause Form sections to be duplicated?

• What Domain should Update sets be Committed From?
• Since Customer Updates have a field called Update Domain, Should the Committing match the Domain on the customer update?
• What Domain Should a record be captured, a record like Forms and Form Sections?
• What if it's a custom Application, and the Custom Table extends from Task?

[ajeet2 · Accepted solution]

Hi @Manny11 ,

Update set should be always commited while being in the global domain regardless of domains of specific records captured as customer updates. 

We need to capture changes to any domain separated configurations carefully as those should be always done while being in the same domain where the record exist unless the existing configuration is supposed to be overriden.

Working with forms consists of activities on the three domain separated tables accessible via:-
/sys_ui_form_list.do [Form record]
/sys_ui_section_list.do [form section record]
/sys_ui_form_section_list.do [Association of form with form section]

Before modifying form configurations , ensure to verify the existing records in all of these three tables to understand the available domain hierarchy for what we have the existing form configurations.

Depending on what we are trying to achieve your session domain should be selected as:-
Mopdifying the pre existing form configuration in the specific domain:- We shoule modify the form while being in same domain in which the pre existing configuration belongs to
Overridding the existing form configuration for another domain:- We shoule modify the form while being in target domain for what we are looking to override the form.

Things to verify in your update set :-

-if there were no duplicate forms captured as customer update

-if overrdie was implemented correctly (if that was to be created)

Regards,

Ajeet

[CarlosAndrC]

Hello @Manny11 I´ll hope yo be great, have you test the suggestion? if you did it, Could you resolve the issue?

Regards,

Carlos Andrés 🙂

[Manny11]

The High Ticket team with UX Development team from ServiceNow responded: 

Hey Emmanuel,

It looks like we're dealing with PRB1463011/KB0951888. The workaround for this, according to the UX team is to create your forms, views, and sections individually on each instance and not try to move them through update sets. If that's not an option, then the recommendation is manual cleanup of the duplicated global components.

There is a workaround script but I we couldn't get it working properly. I wish I had a better response for you. Please let me know if there's anything else related to this case that I can help with.

[Manny11]

A solution I found: 

 Goal

To ensure sys_ui_form records are consistent and deduplicated across environments — with preserved sys_id continuity — by:

1. Comparing post-commit data against the previous environment
2. Removing duplicate records (same table/view, different sys_id)
3. Automatically clearing the form cache

Solution Architecture

Component	Purpose	Location
Scripted REST API	Exposes sys_ui_form data (table, view, sys_id)	Dev & Test
REST Message	Queries the upstream environment for source-of-truth	Test & Prod
Cleanup Script	Runs post-commit to find and remove duplicates	Test & Prod

 Promotion Path Logic

Target Env	Calls	API Hosted In	Purpose
Test	Dev	Dev	Clean up Test after Dev promotion
Prod	Test	Test	Clean up Prod after Test promotion

Component Details

1. Scripted REST API

• Exposes the current environment’s sys_ui_form records
• Returns table, view, sys_id, scope, and domain
• Used as the "source of truth" by downstream environments

1. REST Message

• Defined in Test and Prod
• Calls the upstream REST API to get the list of valid records
• Used by the cleanup logic to find mismatches

1. Cleanup Script

• Runs after update set commit
• Compares local sys_ui_form records to upstream list
• Deletes any with matching table/view but different sys_id
• Clears form cache to prevent rendering issues

Benefits

• Ensures consistency: Matching sys_ids across environments
• Eliminates duplicates: Prevents UI issues and form layout conflicts
• Automates manual work: No more hunting down rogue forms
• Scales well: Easily expanded to handle sys_ui_view, sys_ui_section, etc.
• Supports governance: Promotes source-of-truth model across environments

 Security Notes

• The REST API is locked to basic auth or OAuth and only exposes necessary data
• Scoped app structure keeps logic modular and deployable

🛠 Implementation Summary

Step	Responsible Team	Notes
Deploy Scripted REST API	Platform/DevOps	In Dev and Test environments
Configure REST Messages	Platform/DevOps	In Test and Prod
Run cleanup script post-commit	DevOps/Release	Via scheduled job or background script

🧩 Optional Enhancements

• Extend to sys_ui_section and sys_ui_view
• Add preview mode (log-only) for visibility before deletion
• Bundle all logic in a deployable Scoped App