We've been implementing ServiceNow GRC for a few quarters and have hit a persistent issue that's impacting our audit closure metrics. Mitigation tasks, assigned via the standard workflow, are inexplicably disappearing from the assignee's inbox in certain conditions. The tasks remain in the system (visible via `task_sla` table queries), but the user's inbox view filters them out.
From our investigation, this isn't universal. It seems correlated with:
* Users who belong to multiple groups with different GRC roles.
* Tasks generated from a scoped application's custom workflow activity.
* The `assigned_to` field being populated via a scripted assignment rule, rather than a static assignment.
We've ruled out simple ACLs, as the users can see other tasks from the same table. Our leading hypothesis is a conflict in the `sys_choice` values for state or a mismatch in the expected `task.escalation` value. Has anyone else deconstructed the inbox filter logic for GRC tasks?
A snippet from a diagnostic script we ran to compare a "visible" versus "vanished" task:
```javascript
// Both tasks have similar grc_task properties
var t1 = new GlideRecord('task_sla');
t1.get('sys_id', VISIBLE_SYS_ID);
var t2 = new GlideRecord('task_sla');
t2.get('sys_id', VANISHED_SYS_ID);
gs.info('T1 State: ' + t1.state + ' | Assignment Group: ' + t1.assignment_group);
gs.info('T2 State: ' + t2.state + ' | Assignment Group: ' + t2.assignment_group);
// Output shows both in '3' (Work in Progress), same assignment group.
```
The core question: what conditions, beyond the standard `assigned_to` and `state`, determine inbox visibility for a GRC mitigation task? Specifically, are there hidden filter rules in the `sp_grc_task` inbox definition or a dependent `sys_filter` that might be excluding tasks when certain relationship criteria aren't met? Any insights into the exact OOB inbox query would be invaluable.
- kelly
Data is not optional.
Check the catalog client script for the inbox view. The filter isn't just raw ACLs, it's often a client-side conditional that's looking at the user's *current* group context. If someone's in multiple groups with different roles, the script might evaluate to false when loading the inbox.
Your snippet stops mid-query, but if I had to guess, compare the `group` and `assignment_group` fields between your visible and vanished tasks. A scripted assignment might not be setting the expected supporting fields the inbox widget uses.
Also, `sys_choice` is a red herring. That's for UI labels. Look at the `task_sla.condition` field or the parent workflow activity's output map.
show the math
You're right to point at the inbox view's client-side logic. The standard GRC inbox widget (`sp_grc_inbox_task`) does indeed apply a filter that can be context-sensitive.
A specific nuance: the widget often references `grc_profile` and the user's active group session, not just their group membership. If a user switches their group context via the group picker, the filter's evaluation changes dynamically. This is why comparing `assignment_group` alone isn't enough; you need to check if the `assigned_to` field's value aligns with a `grc_profile` that is active for the user *in the current session*. A scripted assignment might set `assigned_to` correctly but fail to update the supporting `grc_profile` or `group` field the widget's filter depends on.
You can test this by having an affected user explicitly set their group context to the one referenced in the missing task's `assignment_group` field, then reload the inbox. If the task appears, you've isolated the issue to the session-aware filtering.
Oh that's a great point about the script maybe not setting the supporting fields. I've seen something similar where a script sets `assigned_to` but the inbox filter is actually checking against `assignment_group` for its logic, so they fall out of sync. That would totally make them vanish from the view.
Could this also happen if the script runs on a business rule with different timing? Like, if it sets the fields after the initial task creation, maybe the inbox widget's initial filter caches something? Just thinking out loud.