How to Capture Portal Content in Content Publishing and move to next Instances

[lakshmi2002]

Hi All,

I am currently working with Content Publishing in ServiceNow on a custom portal built using Service Portal, where content is displayed using Content Publishing blocks.

In our implementation, a Portal Content record is being rendered through the "Rich Content (CD)" widget instance. It contains multiple blocks such as text, buttons.

I recently updated the redirection URL of a button for one of the button blocks. The change is working correctly in the current instance; however, I noticed that the modification is not being captured in the update set.

Could someone please advise on the recommended approach for promoting this change to higher environments?

• Should I use Force Record to Update Set on the Portal Content record?
• Should I export/import the record as XML?
• Is there another recommended method for migrating changes made within Content Publishing records?

Please help me with this query.

Thank you

[vinay167]

Why your change isn't in the update set

Update sets only capture records in tables flagged as configuration (the update_synch dictionary attribute). Content Publishing records — the Portal Content record, its child block records, and their images/attachments (the sn_cd_content_base family in the Content Publishing scope) — are data, not configuration, so the platform ignores them by design. ServiceNow treats published content the same way it treats knowledge articles or catalog data: it's expected to be authored per instance, and clones from prod will overwrite it in sub-prods.

One detail worth knowing for your specific case: the button URL almost certainly lives on a child block record (or a field within it), not on the Portal Content record itself. So even if you force the parent record somewhere, your actual change can still be left behind. Check sys_updated_on across the content record and its related block records to pinpoint exactly what was modified.

Your three options

1. Force to Update Set — Technically works, but it's a workaround, not the recommended path. If you do it, you must force every changed record (the block record with the URL, plus the parent and any attachments if they changed too), either via the community "Force to Update Set" UI action or a background script using GlideUpdateManager2().saveRecord(). Reasonable if you're bundling this into a larger portal release, but easy to miss child records, and ServiceNow's own guidance is that update sets are for config, not data.

2. Export/Import XML — This is the commonly recommended approach for one-off content migrations. Export the changed record(s) with sys_ids intact and import into the target. Two big caveats:

• Sys_ids must match between instances. If the content was originally created independently in each environment (rather than migrated or cloned), the XML import will create a duplicate instead of updating the existing record.
• The publish state does not carry over — after importing, you must re-publish the content in the target instance for the change to appear on the portal. This is confirmed expected behavior in the community.

3. The simplest recommended method: just make the edit in the target instance. For a single button URL change, honestly the cleanest, lowest-risk path is to open the Content Publishing editor in the higher environment, make the same change, and publish. No sys_id risk, no missed child records, no republish gotcha. This is also the operating model ServiceNow assumes — content authors typically work directly in production, which is exactly why these tables aren't update-set tracked. If your organization needs systematic content sync between instances on an ongoing basis, Instance Data Replication (IDR) is the platform-supported tool for replicating data tables (subject to licensing).

My recommendation for your scenario

For this one change: re-do it in the target via the Content Publishing UI and publish. If your change-control process demands a packaged migration artifact, use XML export/import of the specific changed block record(s), verify sys_ids exist in the target first, and re-publish after import. Reserve Force-to-Update-Set for cases where content changes must ride along with a config release, and document exactly which records you forced.