ServiceNow: Steps of Scheduled Email for an existing report not capturing in local updateset

Create a Scheduled Email of an existing report, push your update set to another environment, and the scheduled report simply isn't there. This isn't a bug, and it isn't something that's changed across ServiceNow versions — it's deliberate platform behavior, and it's still true on current releases. Community threads reporting this exact issue go back to 2019 and as recently as late 2024, which tells you it's architectural, not a defect waiting to be patched.

Why This Happens

Whether a table's changes get captured in an update set at all comes down to a single dictionary attribute: update_synch. A table needs update_synch=true set on its dictionary definition for the platform to track changes to its records as update set entries. Tables that don't have this attribute — sysauto_report (Scheduled Reports) among them — simply aren't watched by the update set mechanism, no matter what you change on them.

This is intentional, not an oversight. Update Sets are built to move configuration — business rules, client scripts, UI policies, workflow definitions — between environments. Scheduled Reports, Scheduled Jobs, and similar records sit closer to data in ServiceNow's own mental model: they reference specific recipients, specific report instances, specific runtime schedules. The platform's default position is that this kind of record shouldn't silently ride along in a configuration migration.

You can check whether any given table is captured by going to System Definition > Dictionary, finding that table's base record (the one with an empty Column name), and checking its Attributes field for update_synch=true.

The Better Fix: Force the Record Into Your Update Set

Rather than exporting and importing XML by hand, you can add a specific record to your current update set directly, using GlideUpdateManager2:

var gr = new GlideRecord('sysauto_report');
gr.addQuery('sys_id', 'your_scheduled_report_sys_id');
gr.query();
if (gr.next()) {
    var um = new GlideUpdateManager2();
    um.saveRecord(gr);
    gs.print('Record added to current update set');
}

Run this from System Definition > Scripts - Background, with the update set you actually want it in selected as your current update set first. This has real advantages over the manual XML approach:

• The record moves through your normal update set promotion process — no separate file to track, remember, or lose.
• The destination environment doesn't need elevated security_admin privileges to receive it, since it's coming in as a standard update set entry rather than a raw XML import.

One limitation to know: GlideUpdateManager2 doesn't work from a scoped application — this needs to run in the Global scope.

The Fallback: Manual XML Export/Import

If you'd rather not run a background script — or you're dealing with a one-off promotion — the manual approach still works exactly as it always has:

Exporting from the source environment:

1. Open the Scheduled Email of Report record.
2. Right-click the list header and select Export > XML (This Record).
3. Save the XML document locally.

Importing into the destination environment:

Because this is a direct XML import rather than a normal update set, the destination environment does require elevated privileges:

1. Click the elevated privileges (lock) icon beside your username, check security_admin in the Activate an Elevated Privilege dialog, and click OK.
2. Navigate to Reports > Scheduled Reports.
3. Right-click the list header and select Import XML.
4. Browse to the XML file and click Upload.

It's Not Just Scheduled Reports

The original version of this article guessed that Scheduled Jobs would have the same problem — that guess was correct, and it's worth being explicit about why, plus a few other categories that catch people off guard the same way:

• Scheduled Jobs (sysauto, sysauto_script) — same root cause, same fix. Use GlideUpdateManager2().saveRecord(gr) against the relevant table, or export/import XML the same way.
• Users, Roles, Groups, and group membership — not captured, by design; these are managed independently of configuration promotion.
• Transactional data — Incidents, Problems, Changes, and similar records are never meant to travel via update set at all. If you need to move this kind of data between environments, that's what Import Sets and Transform Maps are for, not Update Sets.
• Homepages and personal dashboard content — generally not captured either, since these are largely treated as per-user data rather than shared configuration.

If you find yourself needing to move several of these regularly, ServiceNow Share has an "Add to Update Set" utility that generalizes the GlideUpdateManager2 technique above into a reusable tool, rather than writing a one-off background script every time.

The Takeaway

If a change doesn't show up in your update set, the first thing to check isn't whether something's broken — it's whether that table has update_synch=true at all. If it doesn't, that's expected behavior, and GlideUpdateManager2().saveRecord() is generally the cleaner way to move that specific record than a manual XML round-trip.