Discrepancy on sys property sn_itam_restrict_asset_read: Doc says false, Instance defaults to true

[Hitoshi Ozawa]

Hi Everyone,

I wanted to share a finding regarding the system property sn_itam_restrict_asset_read and get feedback from others who are managing recent platform upgrades/installations.

According to the ServiceNow documentation, the property sn_itam_restrict_asset_read is intended to default to false so that baseline read visibility for snc_internal users on alm_asset isn't disrupted unexpectedly.

However, upon checking the audit history on an instance upgraded to Australia, this system property actually initialized at creation (Update Number 0 by System) to true.

When true, users holding only the snc_internal role are immediately restricted to seeing only asset records where they are explicitly referenced (e.g., Assigned to, Reserved for, Managed by, Owned by).

1. Fresh Installs vs. Upgrades: Is anyone else seeing true as the hardcoded default on fresh family instances vs. upgrades from previous releases?

2. Platform Strategy: Is ServiceNow shifting toward a strict "secure by default" posture for ITAM tables out-of-the-box, making the documentation outdated, or is this an unintended initial dictionary value?

3. Workflow Impacts: Has anyone experienced broken catalog items or portal scripts due to this property defaulting to true unexpectedly after a fresh deployment?

Curious if others have logged HI/Support cases on this discrepancy or if setting it manually back to false is the standard workaround you're applying during initial instance provisioning.

Thanks!

[SaurabhT7455244]

I’d treat this as a likely initialisation defect or application-version-specific behaviour, not as evidence of a deliberate “secure by default” change.

If the audit shows Update 0 / System / true, the value was almost certainly seeded when the property was created, rather than changed later by an admin. Given that the documentation still states the default is false, I’d compare the installed HAM/ITAM application versions between Dev/Test/Prod and raise a HI case with ServiceNow.

I also wouldn’t make false part of a standard provisioning workaround until Support confirms the intended default. Changing it affects asset visibility across alm_asset and child tables, so it can have wider security implications than just fixing portal/catalog behaviour.

The key evidence to provide Support is:

• Property: sn_itam_restrict_asset_read
• Documented default: false
• Actual initial value: true
• Audit: Update 0, updated by System
• Family/application version where observed
• Comparison against another instance where behaviour differs

That should be enough for ServiceNow to determine whether this is a plugin seed-value defect, upgrade script issue, or undocumented product change.