- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-08-2025 08:53 AM
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?
Solved! Go to Solution.
- Labels:
-
Architect
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-19-2025 03:27 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-19-2025 03:27 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-24-2025 11:07 AM
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 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2025 10:32 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2025 10:37 AM
A solution I found:
Goal
To ensure sys_ui_form records are consistent and deduplicated across environments — with preserved sys_id continuity — by:
- Comparing post-commit data against the previous environment
- Removing duplicate records (same table/view, different sys_id)
- 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
- 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
- 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
- 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