One Report, Many Paths: A Guide to ServiceNow Report Distribution

Getting a report in front of the right people at the right time is rarely as simple as "just email it." ServiceNow actually offers several distinct ways to distribute a report, and they're not interchangeable — a live dashboard link, a scheduled email attachment, and a self-service subscription all solve different problems. This guide covers the full set of options, not just the one most people default to.

One prerequisite applies across all of them: the report needs to already exist in ServiceNow before you can schedule, publish, or subscribe to it.

Option 1: Scheduled Email of Report

This is the classic approach — a report gets emailed to a defined list of recipients on a recurring schedule, as an attachment. It's a good fit when the audience is fixed (a distribution list, a leadership team) and doesn't need to log into the instance to see it.

There are two ways to set this up, and they land in the same place:

Via the Scheduled Reports module:

1. Navigate to Reports > Scheduled Reports (or the Scheduled Reports link next to Administration on the Reports view/run screen).
2. Click New.
3. Fill in the schedule details, then click Save.

Fields to fill in:

• Name — A descriptive name for the schedule itself.
• Report — The report to be sent.
• Email addresses — Recipients; multiple addresses can be comma-separated.
• Schedule — When and how often it runs (daily, weekly, a specific time).
• Subject and Message — The email's subject line and body text.
• Type — The delivery/export format (see below).
• Run as — The user context the report runs under — commonly a system account, so the schedule doesn't break if the creator's account is later deactivated.

Via the report itself (current UI path): open the report, click Share in the report header, and select Schedule. This opens the same underlying scheduling configuration without leaving the report you're already looking at — generally the faster path if you're already viewing the report you want to distribute.

Either way, all resulting schedules are visible and manageable from the Scheduled Reports module afterward.

Choosing a Delivery Format — This Is Where "Report Type" Matters

The available export/delivery formats depend on what kind of report you're sending:

• List-based reports can be delivered as Excel, CSV, XML, or PDF, depending on your role's export permissions.
• Graphical reports (bar, pie, trend, and similar non-list visualizations) export as PDF, PNG, or JPEG.
• Embedded PNG is worth calling out specifically: instead of attaching the report as a separate file, it drops the report image directly into the body of the email. For a quick visual chart someone just needs to glance at, this is often a better experience than making them open an attachment.

Whichever format you choose, it's worth setting expectations with recipients that a scheduled or exported report is a snapshot at send time, not a live view — the underlying data keeps changing, but the emailed copy doesn't update itself. For audiences that need current data rather than a point-in-time snapshot, one of the options below is usually a better fit.

Option 2: Report Subscriptions (Self-Service)

Rather than an admin setting up a schedule on someone's behalf, ServiceNow also supports Report Subscriptions, which let individual users subscribe themselves to a report they have access to — no separate admin configuration step required for each new subscriber. This is a good fit when a report is broadly useful across a team and you don't want to maintain a manually curated recipient list every time someone joins or leaves.

Option 3: Publishing a Report (Live URL)

For cases where a static emailed snapshot isn't good enough — say, a report that needs to reflect current data whenever someone checks it — a report can instead be published to a shareable URL:

1. Open the report, click the dropdown next to Save, and select Publish.
2. The report's public URL appears at the top of the form — copy it into an email, a wiki page, or wherever it needs to be shared.
3. Anyone with the link sees the report reflecting live data at the moment they open it, not a snapshot from whenever it was last emailed.

Publishing requires the report_publisher role in addition to normal report access, so this isn't available to every user by default. Note also that the underlying data is only visible through the published view itself — someone without direct instance access and permissions can't drill into the raw records behind it.

Option 4: Gauges on a Homepage

A report can also be added to a homepage as a Gauge — a small, refreshable widget that shows live report data without needing an email or a separate link at all. This fits well for a report someone (or a whole team) wants visible every time they land on their ServiceNow homepage, refreshed automatically rather than delivered on a schedule.

Worth a performance note: every Gauge refresh runs a live database query. On a busy homepage viewed by many users, frequent refresh intervals can add unnecessary load — reasonable refresh cadence is worth considering rather than defaulting to the shortest interval available.

A Related but Separate Option: Performance Analytics

If what's actually needed is trend-based KPI reporting — tracking a metric over time rather than a single point-in-time report — that's the domain of ServiceNow's separate Performance Analytics application, which has its own scheduling and distribution capabilities for data visualizations. It's a different license and a different tool from standard Reporting, so it's worth confirming which one actually fits the request before building out a solution in the wrong place.

Which Option Actually Fits?

Need	Best Fit
Fixed recipient list, doesn't need instance access	Scheduled Email of Report
Quick visual glance, no attachment friction	Scheduled Email with Embedded PNG
Broad audience that self-manages who's subscribed	Report Subscriptions
Recipients need current, not point-in-time, data	Publish (live URL)
Visible every time someone lands on their homepage	Gauge
Trend/KPI tracking over time	Performance Analytics

Most reporting requests map cleanly to one of these once the actual need — audience, freshness, and access — is clear. The most common mistake isn't picking the wrong format inside Scheduled Reports; it's defaulting to a scheduled email attachment for a case where a live link or a Gauge would have actually served the audience better.

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.