Limit users to update incidents based on assignment group
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I'm trying to create a custom role to limit users update incidents based on assignment group.
a user in "xyz" group and granted this custom role, can only view and update incidents if assigned to "xyz" group.
i.e. if an incident is assigned to "xyz" group. users (with this custom role) can view and update the incident.
if incident is NOT assigned to "xyz" group. users (with this custom role) CANNOT view or update the incident.
any help will be useful.
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Greetings @WaledBajukhaif. To achieve this, I would recommend creating two new Access Controls (ACLs). You will need one "read" ACL and one "write" ACL (if you are considering delete as "update", then you would need a third ACL of the Operation type "delete").
These two ACLs will require BOTH a Role and a Data Condition. I'm not sure if "xyz" is a specific hard-coded Assignment Group where this one and only Assignment Group is allowed to update Incidents or if "xyz" is a dynamic Assignment Group that represents any Assignment Group that the current signed in user is a member of.
In my Personal Development Instance (PDI), I created a dummy Role called "xyz". I then went to the Access Control table [sys_security_acl] where I created a new ACL.
Note: In order to create ACLs, you must first elevate your Role to security_admin.
Now that you have elevated your Role to security_admin, you are now able to create a new ACL. Click on the New button from list-view to access the ACL form.
As you can see, this ACL record will be for a "write" Operation. You will need to repeat this process for the "read" Operation. The Name field is pointing to the Incident table where this ACL will be applied against.
If you scroll down to the "Requires role" section, you will be given the option to add your custom Role. Again, for this example, I am using the dummy Role I created earlier called "xyz".
Finally, scroll down until you get to the Data Condition section. Here you will have access to a Condition Builder which should be familiar if you've ever interacted with a ServiceNow table before. Depending on what Assignment Group you are intent on using, you can use the example shown here of [Assignment Group > is (dynamic) > One of My Groups] or if there is one and ONLY Assignment Group that you wish to allow write access you can update this Data Condition to be [Assignment Group > is > xyz].
One other thing to note is this is not the only way to achieve your desired outcome, but I believe they will all be some form of an ACL solution. Instead of using a Data Condition, I have seen instances where an Advanced Condition is used and either performs the scripting logic within the Script field directly on the ACL form or the Script condition calls a Script Include which handles the logic within a Script Include function and returns a true/false value.
I hope this information is helpful to you and always happy to hear from others for additional insights.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @lpruit2
Thanks for your help,,
I've done all the steps but did not work, might be something i missed..
I created Read and Write ACLs and created a role "incident.xyz.group" but did not work see attacheds.
I've added the role to "abel.tuter" and he's in xyz group.
but when impersonated him i did not see any incidents.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
the best practice to use here is a two-pronged approach:
Before Query Business Rule: To handle the View (hides the incidents entirely from the list).
Write ACL: To handle the Update (prevents editing the form).
1. Use Before Query business rule
Script:
(function executeRule(current, previous /*null when async*/) {
// 1. Check if user has the restricted role AND is not an admin
// Admins should usually see everything for troubleshooting
if (gs.hasRole('your_custom_role') && !gs.hasRole('admin')) {
// 2. Get the groups the current user belongs to
var user = gs.getUser();
var myGroups = user.getMyGroups();
// 3. Limit the query to only show records where Assignment Group is in user's groups
// If the user has no groups, this adds a query that effectively returns nothing
if (myGroups) {
current.addQuery('assignment_group', 'IN', myGroups);
} else {
// If user is in no groups, they see nothing
current.addQuery('assignment_group', 'Is', 'NULL');
}
}
})(current, previous);
2. Create ACL
Type: Record
Operation: write
Name: Incident [incident] | None (applies to the whole record)
Requires Role: Add your your_custom_role.
Script :
answer = gs.getUser().isMemberOf(current.assignment_group);
Happy to help! If this resolved your issue, kindly mark it as the correct answer ✅ and Helpful and close the thread 🔒 so others can benefit too.
Warm Regards,
Deepak Sharma
Community Rising Star 2025