- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-23-2019 08:11 AM
I have a Control owner who is responsible for the overall control. (e.g. Do capacity trend analysis on servers)
There are multiple manual Type Indicator Tasks linked to this Control. (e.g. Check CPU trends, Check Disk usage trends etc.)
Each Indicator Task must be assigned to a different assignee.
ServiceNow GRC automatically assigns the Tasks to the Control Owner who is also the assignee on the Indicator where the field is not enabled for Edit.
How can Indicator Owner be made different to the Control Owner or is there a better way for achieving the above?
thank you
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-24-2019 01:34 AM
Hi Arno,
I agree that the out-of-the-box idea that Control's owners have to re-assign all indicator tasks manually only make sense for controls that are not assessed on a regular and frequent basis. 😅
I found that the Owner displayed in the Indicator form is a dot.walked field from the "Applies to" field. You can never update dot.walked field because that would change the owner of the control itself. This is exactly why "Owner" and "Owning group" are displayed as read-only.
So, Indicators doesn't have Owner, but Indicator Tasks have Assigned_to.
If the tasks' owner are predictable you could create a few Business Rules to reassign each task. That would be the quick & dirty approach.
Example: If the newly created indicator task name is "Check Linux CPU Trend", then change assigned to our Linux Admin.
My best-aproach suggestion would be that you...
- Create a new "Assignee override" field on the sn_grc_indicator table: A reference field pointing to sys_user. This will allow you to set assignees for specific indicators. (OotB, There is an unused "Owner" string field that you may probably ignore as useless).
- Create a new Business Rule on the sn_grc_indicator_task. On insertion of a new indicator task, if the parent indicator have an "Assignee override" set, the assigned_to would be overrided.
If you need more assistance to create the field and business rule, feel free to ask.
In case a last minute manual re-assignation is required: Indicator Tasks, and their Assigned_to field, are read-only in state Closed and Canceled. So normally anyone with the role sn_grc.manager should be able to re-assign the indicator task to someone else, if required.
∴
Best regards from Switzerland
Shiva :¬,
If this reply assisted you, please consider marking it 👍Helpful or ✅Correct.
This enables other customers to learn from your thread.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-24-2019 01:34 AM
Hi Arno,
I agree that the out-of-the-box idea that Control's owners have to re-assign all indicator tasks manually only make sense for controls that are not assessed on a regular and frequent basis. 😅
I found that the Owner displayed in the Indicator form is a dot.walked field from the "Applies to" field. You can never update dot.walked field because that would change the owner of the control itself. This is exactly why "Owner" and "Owning group" are displayed as read-only.
So, Indicators doesn't have Owner, but Indicator Tasks have Assigned_to.
If the tasks' owner are predictable you could create a few Business Rules to reassign each task. That would be the quick & dirty approach.
Example: If the newly created indicator task name is "Check Linux CPU Trend", then change assigned to our Linux Admin.
My best-aproach suggestion would be that you...
- Create a new "Assignee override" field on the sn_grc_indicator table: A reference field pointing to sys_user. This will allow you to set assignees for specific indicators. (OotB, There is an unused "Owner" string field that you may probably ignore as useless).
- Create a new Business Rule on the sn_grc_indicator_task. On insertion of a new indicator task, if the parent indicator have an "Assignee override" set, the assigned_to would be overrided.
If you need more assistance to create the field and business rule, feel free to ask.
In case a last minute manual re-assignation is required: Indicator Tasks, and their Assigned_to field, are read-only in state Closed and Canceled. So normally anyone with the role sn_grc.manager should be able to re-assign the indicator task to someone else, if required.
∴
Best regards from Switzerland
Shiva :¬,
If this reply assisted you, please consider marking it 👍Helpful or ✅Correct.
This enables other customers to learn from your thread.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-24-2019 03:48 AM
Thanks for the feedback Shiva.
I will keep your recommendations in mind.
I eventually ended up breaking down the Policy Statement into several Policy Statements/Controls/Indicators.
E.g. One for "Check CPU", one for "Check Disk" etc.
Lots of initial admin, but hopefully will pay off in the long run when the auditors arrive. 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-03-2021 10:29 PM
Hi Shiva,
Could you please help with the BR.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-17-2024 05:33 AM
A business rule by itself won't fix this, because the records are created by the script include ManualIndicatorStrategyBase which has setWorkflow(false) in the script, and thus the business rule wouldn't run on the initial insert. You could override the function createIndicatorTask, you'd just have to be careful whenever ServiceNow upgrades in case they have a change to that function (which because you'd override it, you wouldn't be using that new code).