VR (Zurich) Remediation Task Rules with “Created < daysAgo(30)” stop working over time — looking for

[John147]

Hi everyone,

We’re running ServiceNow Vulnerability Response (VR) on Zurich and are facing a recurring issue with Remediation Task Rules that include a time-based condition, such as:

• Created < javascript&colon;gs.daysAgo(30)

Background / Goal

Our intention is to delay remediation task creation until a 30‑day patch window has passed (we don’t want to create remediation work immediately because Windows patching is expected to resolve many findings automatically within the first 30 days). After the 30 days are over, we want the findings to be automatically grouped into remediation tasks, one task per unique vulnerability, and all endpoints with the same vulnerability should be added to the same task (grouped by Vulnerability). 

We also have only one assignment group handling this scope (e.g., CI name starts with a specific prefix).

Current Configuration

• We use a Remediation Task Rule / Grouping Rule with conditions similar to:
  • cmdb_ci.name STARTSWITH <prefix>
  • sys_created_on < javascript&colon;gs.daysAgo(30)
• Grouping is intended to be by vulnerability.

The Problem

It works initially, but over time it stops creating tasks automatically. We then have to manually Reapply the Remediation Task Rule to make it work again.

From the product docs, it seems this may be expected behavior because Vulnerable Items are evaluated against remediation task rules when the VI is created/imported/reopened, and not re-evaluated just because time passes.
So a VI that is younger than 30 days at ingest will not match the rule at that time, and it won’t be automatically re-checked when it becomes older than 30 days.

What We Tried

• We set system property sn_vul.rerun_task_rules = true, but this did not solve the “age-based” issue.
  • Based on the docs, this property seems mainly intended to support regrouping when assignment changes via assignment rules (and requires the “Link to Remediation Tasks” business rule), not for time-driven re-evaluation of age conditions.

Why “Reapply” is not an option

• Reapplying remediation task rules is heavy and can delete/recreate remediation tasks, which is disruptive (record churn, noise, potential loss of continuity). The docs also describe reapply as time-consuming in classic UI.

What We Want (OOTB if possible)

We want a consistent OOTB approach that achieves:

1. Automated (e.g., daily) evaluation so that when VI age crosses 30 days, it gets grouped and a remediation task is created.
2. One remediation task per vulnerability, and all matching endpoints added to that task while it remains Open. 
3. Preferably no custom scripts / no destructive reapply behavior.

Potential Direction (Looking for confirmation / best practice)

I found documentation for Re-evaluate remediation properties in the Vulnerability Manager Workspace, which can selectively update Remediation tasks according to the latest Remediation task rules.
However, I’m unsure if there is an OOTB way to schedule this re-evaluation daily for a filtered set (e.g., “CI name starts with X AND Created < daysAgo(30)”).

Questions

1. Is there any OOTB scheduled job or OOTB automation to periodically re-evaluate remediation task rules for aging conditions (e.g., daysAgo(30)), without using Reapply? 
2. If not, what is the recommended OOTB pattern to delay task creation until day 30, while still grouping by vulnerability?
3. Is the best-practice approach to:
   • create tasks immediately and rely on targets/notifications (instead of delaying task creation), or
   • use the Workspace Re-evaluate capability in an automated way?

Any guidance from people who implemented a similar “delay until X days” pattern in VR (Zurich) while staying OOTB would be greatly appreciated.

Thanks!