How are you managing the lifecycle of Core UI reports during Platform Analytics migration?

[MonfardiniS]

We're currently reviewing and cleaning up Core UI reports as part of our preparation for wider adoption of Platform Analytics and have come across a few challenges around report lifecycle management.

During this exercise we have found a number of unexpected behaviours:

• The report Last run field does not appear to be updated when a report is only consumed through scheduled email distribution and is never viewed directly in the instance.
• A report with sys_report.active = false can still be distributed successfully through a scheduled report email.
• Single dashboard migration activities from Core UI to Platform Analytics can result in some reports becoming inactive (where the report is present on multiple dashboards), whilst other reports remain active (where the report is only present on a single dashboard).
• Reverting a dashboard migration back to Core UI does not restore the original active state of any reports that were made inactive during the migration (I would love for this to not be the case or to change in the future so I have submitted an idea related to this)

Taken together, this makes report lifecycle management more challenging.

For example:

• An inactive report is not necessarily an unused report.
• A report that appears not to have run may still be delivering value through scheduled email distribution.
• The Active flag can be changed by migration activities as well as by administrators managing report lifecycles.

This has raised a few questions for us:

1. How are other customers identifying reports that are genuinely no longer required?
2. Are you taking scheduled report distribution into account when assessing report usage and retention?
3. How are you distinguishing between reports made inactive through your own lifecycle processes and reports made inactive by Platform Analytics migration activities?
4. Is there any documented ServiceNow guidance on governance, retention, and cleanup of Core UI reports during the transition to Platform Analytics?
5. Has anyone developed a reliable approach for identifying reports that are safe to archive or delete?

I'd be interested to hear how others are approaching report governance in larger environments, particularly where there are significant numbers of legacy reports, dashboards, and scheduled report distributions.

Thanks,

Sophia

[Dan_Junqueira]

Hi Sophia @MonfardiniS 

This is a really good point, and I think the biggest takeaway from what you found is that Active and Last run can no longer be treated as reliable lifecycle indicators by themselves.

I would be very cautious about deleting anything based only on those two fields.

The approach I prefer is to treat a report as a retirement candidate only when several things are true at the same time:

• it has not been run interactively for an agreed period;

• it is not referenced by an active scheduled report;

• it is not being used on a dashboard that is still in use;

• it is not still required as part of the Platform Analytics migration;

• and ideally the owner or business area has confirmed that it is no longer needed.

Scheduled reporting is probably the biggest trap here. I would definitely include sysauto_report in the analysis rather than relying on Report Stats.
A report may look completely unused from a user-interaction perspective and still be sent every Monday morning to 50 people.

The migration also makes the Active flag more complicated. ServiceNow actually documents that when you migrate an individual Core UI report, the original report is set to Active = false.

The same principle applies when scheduled reports are migrated to Scheduled Exports. So at that point, inactive can mean “retired”, but it can also mean “successfully migrated”.

Because of that, I would probably add another layer of governance rather than trying to infer everything from sys_report.active. Something as simple as a lifecycle status such as In Use / Migration Candidate / Migrated / Pending Retirement / Retired can save a lot of confusion in a large environment.

I would also archive before deleting. Give owners a period to challenge the retirement, keep enough information to reconstruct the report if necessary, and only physically delete it later.

ServiceNow does provide good guidance around the migration process itself, particularly the recommended migration path and reviewing the content in sub-production, but I haven't seen a single prescriptive retention policy that answers “this report is definitely safe to delete”.

I think that part still needs to be defined as customer governance.

So yes, I would absolutely take scheduled distribution, dashboard usage, migration state and ownership into account before making any cleanup decision.

Your findings are a good example of why a simple “Last run older than 12 months = delete” rule can be dangerous during this transition.

Hope this helps. If it does, please mark the response as useful.