Hi @MBarrott,
I agree with @AndersBGS: there is no out-of-the-box feature for this, and the recommended approach is to build dashboards per persona (one for managers, one for fulfillers) and share each one with the right group or role. That keeps everything configurable, with no code to maintain.
That said, if the business really needs a single dashboard, below is a custom alternative that I built and tested on a Brazil PDI.
Important: this is a custom solution, not OOTB
Anything outside of OOTB functionality is not a recommended practice by default. This approach adds custom code (a script include and a custom dynamic filter option) that your team will need to maintain, retest on every upgrade, and document properly. I would only use it if the business explicitly requires it, and I would record the decision (business requirement, owner, and technical design) so future admins understand why it exists.
How it works
A custom dynamic filter option runs a script include for the logged-in user:
- If the user is a member of a managers group, it returns all active users with the itil role.
- Otherwise, it returns only the logged-in user, the same way the OOTB "Me" option works.
Step 1. Create the managers group
Create a group (in my test, "Dashboard Managers") and add the managers as members. Membership in this group is what decides who sees the full list.
Step 2. Create the script include
- Name: DashboardUserFilter
- Accessible from: All application scopes
- Sandbox enabled: checked. This is required for script includes used in filters since Washington; without it, the dynamic filter returns nothing.
var DashboardUserFilter = Class.create();
DashboardUserFilter.prototype = {
MANAGER_GROUP: 'Dashboard Managers',
initialize: function() {},
getSelectableUsers: function() {
if (gs.getUser().isMemberOf(this.MANAGER_GROUP)) {
return this._getItilUsers();
}
return [gs.getUserID()];
},
_getItilUsers: function() {
var users = [];
var ga = new GlideAggregate('sys_user_has_role');
ga.addQuery('role.name', 'itil');
ga.addQuery('user.active', true);
ga.groupBy('user');
ga.query();
while (ga.next()) {
users.push(ga.getValue('user'));
}
return users;
},
type: 'DashboardUserFilter'
};Note that the function returns an array of sys_ids, not a comma-separated string.
Step 3. Create the dynamic filter option
Go to System Definition > Dynamic Filter Options and create a new record:
- Label: Selectable dashboard users (any descriptive name works)
- Script: new DashboardUserFilter().getSelectableUsers()
- Field type: Reference
- Referenced table: User [sys_user]
- Available for filter: true
- Active: true
Step 4. Filter the data on the visualization
In the data source of each visualization (for example, Incident), add the condition:
Assigned to | is (dynamic) | Selectable dashboard users
This is the part that filters the data on load, so fulfillers only see their own records without having to pick anything.
Step 5 (optional). Restrict the dashboard filter dropdown
If you also want the user filter at the top of the dashboard to be limited, add a filter with source User [sys_user] and the condition:
Sys ID | is (dynamic) | Selectable dashboard users
and map it to Incident > Assigned to. Keep in mind that in Platform Analytics this condition only limits the options in the dropdown; it does not filter the data by itself, which is why Step 4 is needed.
Test results (Brazil PDI)
- A member of Dashboard Managers saw 48 incidents, all assigned to itil users.
- A fulfiller outside the group saw only the 1 incident assigned to them.
- A user outside the group with no assigned incidents saw 0 records.
Considerations
- This is not a security control. It only changes what the visualization shows. If fulfillers must not access other users' records, enforce it with ACLs.
- The group name is hardcoded in the script include. For a real implementation, move it to a system property so it can be changed without editing code.
- In large organizations, returning thousands of sys_ids on every load can affect performance. Test with realistic data volumes.
- Add any other conditions you need, such as Active is true, alongside the dynamic condition.
- Maintenance: the script include and the dynamic filter option must be retested after each upgrade, and documented (purpose, owner, dependencies on the group and the itil role) so the solution can be supported or removed later.
Hope this helps.
https://www.linkedin.com/in/anatamayoservicenow/
Hi @MBarrott,
I agree with @AndersBGS: there is no out-of-the-box feature for this, and the recommended approach is to build dashboards per persona (one for managers, one for fulfillers) and share each one with the right group or role. That keeps everything configurable, with no code to maintain.
That said, if the business really needs a single dashboard, below is a custom alternative that I built and tested on a Brazil PDI.
Important: this is a custom solution, not OOTB
Anything outside of OOTB functionality is not a recommended practice by default. This approach adds custom code (a script include and a custom dynamic filter option) that your team will need to maintain, retest on every upgrade, and document properly. I would only use it if the business explicitly requires it, and I would record the decision (business requirement, owner, and technical design) so future admins understand why it exists.
How it works
A custom dynamic filter option runs a script include for the logged-in user:
- If the user is a member of a managers group, it returns all active users with the itil role.
- Otherwise, it returns only the logged-in user, the same way the OOTB "Me" option works.
Step 1. Create the managers group
Create a group (in my test, "Dashboard Managers") and add the managers as members. Membership in this group is what decides who sees the full list.
Step 2. Create the script include
- Name: DashboardUserFilter
- Accessible from: All application scopes
- Sandbox enabled: checked. This is required for script includes used in filters since Washington; without it, the dynamic filter returns nothing.
var DashboardUserFilter = Class.create();
DashboardUserFilter.prototype = {
MANAGER_GROUP: 'Dashboard Managers',
initialize: function() {},
getSelectableUsers: function() {
if (gs.getUser().isMemberOf(this.MANAGER_GROUP)) {
return this._getItilUsers();
}
return [gs.getUserID()];
},
_getItilUsers: function() {
var users = [];
var ga = new GlideAggregate('sys_user_has_role');
ga.addQuery('role.name', 'itil');
ga.addQuery('user.active', true);
ga.groupBy('user');
ga.query();
while (ga.next()) {
users.push(ga.getValue('user'));
}
return users;
},
type: 'DashboardUserFilter'
};Note that the function returns an array of sys_ids, not a comma-separated string.
Step 3. Create the dynamic filter option
Go to System Definition > Dynamic Filter Options and create a new record:
- Label: Selectable dashboard users (any descriptive name works)
- Script: new DashboardUserFilter().getSelectableUsers()
- Field type: Reference
- Referenced table: User [sys_user]
- Available for filter: true
- Active: true
Step 4. Filter the data on the visualization
In the data source of each visualization (for example, Incident), add the condition:
Assigned to | is (dynamic) | Selectable dashboard users
This is the part that filters the data on load, so fulfillers only see their own records without having to pick anything.
Step 5 (optional). Restrict the dashboard filter dropdown
If you also want the user filter at the top of the dashboard to be limited, add a filter with source User [sys_user] and the condition:
Sys ID | is (dynamic) | Selectable dashboard users
and map it to Incident > Assigned to. Keep in mind that in Platform Analytics this condition only limits the options in the dropdown; it does not filter the data by itself, which is why Step 4 is needed.
Test results (Brazil PDI)
- A member of Dashboard Managers saw 48 incidents, all assigned to itil users.
- A fulfiller outside the group saw only the 1 incident assigned to them.
- A user outside the group with no assigned incidents saw 0 records.
Considerations
- This is not a security control. It only changes what the visualization shows. If fulfillers must not access other users' records, enforce it with ACLs.
- The group name is hardcoded in the script include. For a real implementation, move it to a system property so it can be changed without editing code.
- In large organizations, returning thousands of sys_ids on every load can affect performance. Test with realistic data volumes.
- Add any other conditions you need, such as Active is true, alongside the dynamic condition.
- Maintenance: the script include and the dynamic filter option must be retested after each upgrade, and documented (purpose, owner, dependencies on the group and the itil role) so the solution can be supported or removed later.
Hope this helps.
https://www.linkedin.com/in/anatamayoservicenow/
