Reasons why the "sp_page" field in "sp_container" becomes empty.

mugi-san
Kilo Sage

Hello, Everyone.

 

After migrating an sp_page update via an Update Set, I encountered an issue where some sp_container records placed on the page are no longer displayed.

I suspect this happened because the sp_page field in the sp_container record became empty, or the container records failed to update their references when the sp_page was modified.

I had assumed that using the Service Portal Designer would automatically capture all necessary related records in the Update Set. However, it seems that only the containers directly added or deleted are being recorded.

Has anyone encountered a similar issue?

To resolve this, I am considering manually exporting all related containers and their child records as XML and importing them to overwrite the existing data. Does anyone have a better alternative or best practice for this?

 

Best regards,

1 ACCEPTED SOLUTION

mugi-san
Kilo Sage

Thanks, @SasibhushanC604 , @Tanushree Maiti .

 

Thank you very much for your advice.
I fully understand that the best approach is to implement the recording function within the Update Set and then use it to capture the updates—and I have confirmed that this method works. However, based on your suggestions, I also took the time to verify the migration process using XML.

 

1. Create page

mugisan_0-1778028813658.png

2.Destroy the container (delete Page field value)

mugisan_1-1778028862272.png

3. The page is corrupted

mugisan_2-1778028971878.png

4. Import XML (sp_container record only)

mugisan_3-1778029078287.png

5. The page rendering issues will be resolved after performing a "cache.do."

mugisan_4-1778029270177.png

 


Best regards,

View solution in original post

3 REPLIES 3

SasibhushanC604
Giga Guru

Yes, I’ve seen this behavior before, and your assumption is correct. When working with Service Portal, the Designer does not always capture the full page hierarchy in an Update Set. It typically only records the changes you directly make (like adding/removing containers), but related records such as rows, columns, and widget instances are often not included automatically.

 

A Service Portal page is made up of multiple related records:

  • sp_page
  • sp_container
  • sp_row
  • sp_column
  • sp_instance (widgets)
  • sp_widget (and dependencies)

If any of these are missing or if the reference breaks (especially the sp_page field on sp_container), the containers will not render even though they still exist in the database.

This issue usually happens because:

  • Not all related records were captured in the Update Set
  • References (like sp_page) were not updated correctly
  • Records exist in the target but are not linked properly

Before going with XML export/import, I would recommend a safer approach:

  1. In the source instance, open the page from the sp_page table (not just Designer) and verify all related records (containers, rows, columns, instances) are correctly linked.
  2. Manually add missing records to the Update Set using “Add to Update Set” or “Force to Update Set”. Make sure you include the full hierarchy.
  3. Use “Find Update Set Changes” to confirm what has actually been captured.
  4. Preview the Update Set in the target instance and review skipped records or conflicts.
  5. In the target, check if any sp_container records have an empty sp_page field and re-link them if needed.

Your idea of exporting/importing XML will work, but it should be used as a last resort because:

  • It can overwrite existing changes in the target
  • It may create sys_id conflicts
  • It can break relationships if not all related records are included

If you do go with XML, make sure you export the entire hierarchy (page + containers + rows + columns + instances), not just containers. This is a common limitation with Service Portal Update Sets. The cleanest solution is to ensure the full page structure is captured and migrated together rather than relying only on Designer changes.

Tanushree Maiti
Kilo Patron

Hi @mugi-san ,

 

I’ve encountered this issue multiple times across different clients.


The most reliable solution is to ensure that, while capturing a page, all dependent records (such as widget, instances, containers, etc.) are included in the update set by using the “Force to Update Set” related link.


Even a small oversight can break the page in the target instance, requiring an additional migration to include the missed component.

 

 

 

Please mark this response as Helpful & Accept it as solution if it assisted you with your question.
Regards
Tanushree Maiti
ServiceNow Technical Architect
Linkedin:

mugi-san
Kilo Sage

Thanks, @SasibhushanC604 , @Tanushree Maiti .

 

Thank you very much for your advice.
I fully understand that the best approach is to implement the recording function within the Update Set and then use it to capture the updates—and I have confirmed that this method works. However, based on your suggestions, I also took the time to verify the migration process using XML.

 

1. Create page

mugisan_0-1778028813658.png

2.Destroy the container (delete Page field value)

mugisan_1-1778028862272.png

3. The page is corrupted

mugisan_2-1778028971878.png

4. Import XML (sp_container record only)

mugisan_3-1778029078287.png

5. The page rendering issues will be resolved after performing a "cache.do."

mugisan_4-1778029270177.png

 


Best regards,