Server-Side JavaScript Sandbox - Dispositioning OOTB incompatible Guarded Scripts

[Jeff Boltz1]

Hello Community,

We're reviewing incompatible Guarded Script findings associated with ServiceNow's Server-Side JavaScript Sandbox Replacement and have found that occurrence volume can be somewhat misleading.

In our environment, thousands of occurrences reduce to only a small number of distinct recurring script patterns.

ServiceNow Support has since confirmed that several of our highest-volume patterns are known product issues:

- VisualizationFiltersParser.getCreatedByMe()
- VisualizationFiltersParser.getSharedWithMe()
- VisualizationFiltersParser.getBookmarked()

These are being tracked by ServiceNow as a product issue, with customer-side remediation not expected.

We've also confirmed that:

- sn_flow.AssociatedFlows.getFlows() is associated with a separate known ServiceNow product issue.
- One remaining pattern involving sn_hr_agent_ws.hr_DelegationHelper.getDelegatedTasks() is still under investigation and currently has no identified PRB.

This leaves us with a more interesting engineering/governance question than simply counting incompatible-script occurrences.

For customers or developers who have worked through Sandbox / Guarded Script compatibility:

1. Are you dispositioning findings by unique script pattern rather than occurrence volume?

2. How are you handling findings confirmed to originate from out-of-box ServiceNow code?

3. Are you retaining known product-issue findings for validation after the applicable patch/release, or creating exemptions in the interim?

4. When an application-provided/OOTB pattern has no known PRB, how are you determining whether it requires customer action versus vendor investigation?

5. What criteria are you using to determine when your incompatible Guarded Script assessment is sufficiently complete for future enforcement decisions?

I'm particularly interested in practical engineering approaches for separating customer-owned remediation from ServiceNow/platform-owned findings.

Thanks,
Jeff

[Rafael Batistot]

Hi @Jeff Boltz1 

I recommend tracking unique script patterns by ownership and remediation status, documenting known OOTB issues, engaging ServiceNow Support for unresolved cases, and validating fixes after upgrades before enabling enforcement.

[Jeff Boltz1]

Thanks Rafael, appreciate the response. That aligns well with the direction we’ve been taking, particularly reducing the findings to unique script patterns and then classifying them by ownership and remediation status rather than using raw occurrence volume.

The ownership distinction has been especially useful for us, since several of our highest-volume patterns have now been confirmed by ServiceNow Support as product issues rather than customer-owned remediation.

I also agree on retaining those findings for validation after the applicable product fix rather than treating their current occurrence count as outstanding customer remediation.

Thanks for sharing your approach.

[Tejas Adhalrao]

HI @Jeff Boltz1 ,

I would suggest grouping the findings by unique script pattern rather than looking only at the total number of occurrences. This makes it easier to identify which scripts actually need remediation.

For OOTB scripts confirmed as known product issues, I would document the related PRB and keep them on a separate tracking list for validation after the relevant ServiceNow fix is available.

For patterns without a known PRB, I would first check whether the script belongs to OOTB functionality or customizations. If it is OOTB, I would raise it with ServiceNow Support for further investigation rather than modifying platform code directly. For custom scripts, I would review and remediate the incompatible APIs.

I would also maintain a clear status for each unique pattern, such as customer action required, known product issue, under investigation, or resolved. This gives a more accurate view of readiness for future enforcement than occurrence counts alone.

Regards, Tejas