PA Business Rule "Track artifact creation post-migration"

[Tom Brown]

It appears that when I migrated our instances to Platform Analytics and used their migration tool, it installed about 40 business rules titled "Track artifact creation post-migration" that SN's Impact system is now flagging as bad code.  All it seems to do is update a system property called "glide.par.coreui.migration.new_coreui_artifacts_created" to "true".  Impact's Scan Engine says this is bad practice to set a system property in a script.  I don't see why this BR should run on any insert or update to a sys_report_source, a sys_ui_hp_cascading_filter, or a pa_m2m_dashboard_tab.  Is it hurting anything?  Probably not, just extra BR's to process.  I'd like to clear that finding though.  ServiceNow's AI keeps saying stuff about it being for tracking updates, but I don't see this doing anything like that.  The property been set to 'true' and has not been updated since creation in 2024.  I thought I'd throw this out to the community before opening a case.  Was this supposed to be cleaned up at the end of migration processing?

The entire script:

(function executeRule(current, previous /*null when async*/) {gs.setProperty("glide.par.coreui.migration.new_coreui_artifacts_created", "true");})(current, previous);

[BrunoPer]

"

Issue:
After testing a full Platform Analytics migration with Migration Center, you found 43 business rules named 'Track artifact creation post-migration' across the impacted tables and asked what they do, why they were created, and which ServiceNow documentation explains the behavior.

Business Impact:
These business rules can create confusion during migration validation because they appear on many tables and may look like unexpected custom logic or poor-practice findings, even though they are related to migration tracking rather than day-to-day analytics behavior.

Steps to Reproduce:

1. Open Migration Center in a non-production instance.
2. Run a full Platform Analytics migration for the available Core UI analytics artifacts.
3. Review the impacted tables after migration.
4. Observe that business rules named 'Track artifact creation post-migration' were created on the migrated source tables.

Most Probable Cause:
The business rules were created by the Platform Analytics migration process as tracking artifacts. The official documentation confirms that Migration Center migrates Core UI analytics content into Platform Analytics, runs in the background, and can automatically migrate content that becomes compatible later. A related troubleshooting article documents that the property

glide.par.coreui.migration.new_coreui_artifacts_created

is used to reset migration state when new artifacts need to be processed again. Based on prior resolved support findings, the leftover 'Track artifact creation post-migration' rules are most likely stale tracking rules from an older migration-script path where cleanup did not complete.

Solution Proposed:

1. The behavior is consistent with how Platform Analytics Migration Center works: a full migration moves Core UI dashboards, reports, interactive filters, and Performance Analytics widgets into the Platform Analytics library, and the migration runs in the background.
2. The most likely purpose of the 'Track artifact creation post-migration' business rules is migration-state tracking. The documented migration flow shows that ServiceNow can continue to recognize newly compatible or newly created analytics content after the initial migration, and the related migration property

glide.par.coreui.migration.new_coreui_artifacts_created

is used to reopen migration processing when additional artifacts need to be picked up.

1. In practical terms, these rules are migration bookkeeping rather than business logic for your application tables. Their role is to signal that new Core UI analytics artifacts appeared after the migration run so Migration Center can make additional migration work available instead of treating the migration as permanently complete.
2. For why the rules remained after your test migration, prior resolved support findings indicate this can happen when an older migration-script version created the tracking rules but the cleanup step did not run afterward. That part is based on prior support findings rather than the public product documentation.

Next Steps:
If your goal was explanation only, no action is required. If you want these leftover tracking rules reviewed for cleanup, reply to this case and I will take care of routing that internally for the appropriate follow-up.

***

Best regards,
ServiceNow AI

"