- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-01-2023 12:18 PM - edited 12-01-2023 12:22 PM
Hi,
We have a bunch of assignment rules configured on vulnerable items based on the values contained in resource tag field of discovered items table.
How to re-run assignment rules on vulnerable items when resource tag on discovered item is updated?
For example, a discovered item A contains resource tag 'Servers' and it is assigned to servers team. At a later point, if the resource tag on the same discovered item A is changed to 'Hardware' from 'Servers', the assignment group on VI should be updated to hardware team. What are the best options to configure this?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-22-2023 08:47 AM - edited 12-22-2023 09:04 AM
Hey Sath,
You will need to add a gr.update() statement to save the changes to the sn_vul_vulnerable_item GlideRecord object. I would also suggest adding a verification that the new assignment_group is different before updating and saving the change. This will make your code a little more efficient.
Incidentally, it is best to avoid using "gr" for GlideRecord objects names. This is a relatively recent Best Practice suggestion. You will see it used extensively within OOB code but HealthScan will flag it as an issue. At the very least, I would use either "grVI" or "viGR".
I hope that this helps,
--Joe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-01-2023 02:05 PM
Hey Sath,
I'm not certain from your description but, if this is the process that you want:
- Discovered Item is updated with new Source Data
- A different CI is matched
- Associated VIs are update with the new CI
- VI Assignment Rules are re-run
This may be facilitated by this process:
- Discovered Item.reevaluate_ci field is set true when Source Data changes. Look to see if this is true for Resource Tag changes.
- Scheduled job "Re-apply CI Lookup Rules on the Changed Discovered items" runs against DI records with reevaluate_ci=true. OOB, this job is not run and will need to be scheduled to run regularly.
- When a new CI is matched against the DI, the associated Vulnerable Items are also updated with the new CI.
- Updating the CI on VI triggers a Business Rule that re-runs Assignment Rules.
Here are notes/documentation on this:
- https://docs.servicenow.com/csh?topicname=re-evaluate-discovered-items.html&version=latest
- https://www.servicenow.com/community/secops-articles/reapplying-ci-matching-rules-to-discovered-item...
On the other hand, if the CI remains the same but you want to trigger the Assignment rules anyway, you will probably have to write a Discovered Item Business Rule or Flow that runs logic that is similar to the Vulnerable Item BR named "Run assignment rules". If you decide on a BR, be sure to run it ASYNC so that it does not hold up your processing.
I hope that this helps,
--Joe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2023 07:15 AM
Hi Joe,
Thank you for the information. The CI remains the same and wants to trigger the assignment rules only on change of resource tags on discovered item.
Can we add the condition discovered item.resource tag changes on the BR 'Run assignment rules' similar to the screenshot attached:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2023 09:20 AM
Hey Sath,
No, you do not want to add that condition.
- It would run only when Vulnerable Items are updated and not when Discovered Items have been updated.
- If it ran, it would slow down integrations that insert/update Vulnerable Items. That process is already resource intensive.
Instead, you want a new Business Rule or Flow that is linked to Discovered Items being Updated. Also, you want it to be configured to run independently so that it does not force a process to wait while assignment rules run for associated VI's. This would mean either an ASYNC Business Rule, a Flow (usingFlow Designer), or an Event & Script Action.
I hope that this helps,
--Joe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-05-2023 05:15 AM - edited 12-05-2023 05:15 AM
Thank you, can you please assist with async business rule script for this scenario?