- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-21-2025 04:18 PM - edited 01-21-2025 04:20 PM
Hi All,
We have a new requirement where we're onboarding contractors into our ServiceNow platform to manage specific types of cases across our global offices. As a result, we're creating a new assignment group to grant these contractors access and are looking to use the existing ACLs for read/write access to the cases. However, we'd like to restrict what cases they can view by a field condition on existing cases (i.e. Workplace Service = Package Delivery). I've seen a few suggestions for ACLs, Business Rule Query, COE Security, etc. but I wanted to inquire if anyone has any suggestions or best practices that they can share. Unfortunately this would be on the Workplace (WSD) table so we wouldn't be able to use COE Security.
Is it possible to use existing ACLs and then limit what case the users in this assignment group can view and access?
Thank you in advance!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-21-2025 05:37 PM - edited 01-27-2025 01:00 PM
it's possible to limit what cases the users in this specific assignment group can view and access using Access Control Rules (ACLs), Business Rules, and potentially User Criteria. Here are the best practices and a step-by-step guide to achieve your requirements.
Use ACLs for Read Access on the WSD Table:
- You can create a custom Read ACL to restrict access to cases for users in the contractor's assignment group based on specific conditions, such as "Workplace Service = Package Delivery."
- This will be done at the record level in the WSD table, and you can check the field condition dynamically (e.g., Workplace Service field value).
Example ACL for Read Access:
- Table: WSD
- Condition: Create an ACL condition based on the Workplace Service field.
- Script: Use a script to check if the user belongs to the contractor group and if the case matches the specific criteria (e.g., Workplace Service = "Package Delivery").
Use Business Rules for Field-Level Security (Optional):
- You can write a Business Rule that enforces specific logic when a user tries to view or modify a record.
- You can ensure that users in the contractor assignment group are only able to see specific cases (e.g., when Workplace Service = Package Delivery).
- The Business Rule can either prevent updates or display messages if the condition isn't met.
Example Business Rule for Restricting Access:
- Table: WSD
- Condition: When a contractor tries to access a case that doesn't meet the Workplace Service condition.
Use User Criteria to Define Role-Based Access (Optional):
If your access restrictions are related to a specific user role, you can create User Criteria for contractors. However, if your access control is more complex and needs field-based conditions, ACLs and Business Rules would be better.
Using Security Policies for Additional Control (Optional):
If you have complex security needs, such as requiring contractors to only access certain cases by Workplace Service for every record across multiple tables, you could use Security Policies or COE Security. But since COE Security cannot be used for your table (WSD), ACLs and Business Rules are the best approach here.
ɪꜰ ᴍʏ ᴀɴꜱᴡᴇʀ ʜᴀꜱ ʜᴇʟᴘᴇᴅ ᴡɪᴛʜ ʏᴏᴜʀ Qᴜᴇꜱᴛɪᴏɴ, ᴘʟᴇᴀꜱᴇ ᴍᴀʀᴋ ᴍʏ ᴀɴꜱᴡᴇʀ ᴀꜱ ᴛʜᴇ ᴀᴄᴄᴇᴘᴛᴇᴅ ꜱᴏʟᴜᴛɪᴏɴ ᴀɴᴅ ɢɪᴠᴇ ᴀ ᴛʜᴜᴍʙꜱ ᴜᴘ.
ʙᴇꜱᴛ ʀᴇɢᴀʀᴅꜱ
ꜱʀᴇᴇʀᴀᴍ
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-21-2025 05:37 PM - edited 01-27-2025 01:00 PM
it's possible to limit what cases the users in this specific assignment group can view and access using Access Control Rules (ACLs), Business Rules, and potentially User Criteria. Here are the best practices and a step-by-step guide to achieve your requirements.
Use ACLs for Read Access on the WSD Table:
- You can create a custom Read ACL to restrict access to cases for users in the contractor's assignment group based on specific conditions, such as "Workplace Service = Package Delivery."
- This will be done at the record level in the WSD table, and you can check the field condition dynamically (e.g., Workplace Service field value).
Example ACL for Read Access:
- Table: WSD
- Condition: Create an ACL condition based on the Workplace Service field.
- Script: Use a script to check if the user belongs to the contractor group and if the case matches the specific criteria (e.g., Workplace Service = "Package Delivery").
Use Business Rules for Field-Level Security (Optional):
- You can write a Business Rule that enforces specific logic when a user tries to view or modify a record.
- You can ensure that users in the contractor assignment group are only able to see specific cases (e.g., when Workplace Service = Package Delivery).
- The Business Rule can either prevent updates or display messages if the condition isn't met.
Example Business Rule for Restricting Access:
- Table: WSD
- Condition: When a contractor tries to access a case that doesn't meet the Workplace Service condition.
Use User Criteria to Define Role-Based Access (Optional):
If your access restrictions are related to a specific user role, you can create User Criteria for contractors. However, if your access control is more complex and needs field-based conditions, ACLs and Business Rules would be better.
Using Security Policies for Additional Control (Optional):
If you have complex security needs, such as requiring contractors to only access certain cases by Workplace Service for every record across multiple tables, you could use Security Policies or COE Security. But since COE Security cannot be used for your table (WSD), ACLs and Business Rules are the best approach here.
ɪꜰ ᴍʏ ᴀɴꜱᴡᴇʀ ʜᴀꜱ ʜᴇʟᴘᴇᴅ ᴡɪᴛʜ ʏᴏᴜʀ Qᴜᴇꜱᴛɪᴏɴ, ᴘʟᴇᴀꜱᴇ ᴍᴀʀᴋ ᴍʏ ᴀɴꜱᴡᴇʀ ᴀꜱ ᴛʜᴇ ᴀᴄᴄᴇᴘᴛᴇᴅ ꜱᴏʟᴜᴛɪᴏɴ ᴀɴᴅ ɢɪᴠᴇ ᴀ ᴛʜᴜᴍʙꜱ ᴜᴘ.
ʙᴇꜱᴛ ʀᴇɢᴀʀᴅꜱ
ꜱʀᴇᴇʀᴀᴍ
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-22-2025 07:45 AM
Thanks for the suggestions! A Read ACL seems like the best approach, but we still want our group to be able to view the cases, not just the contractors. Do you think this still would be feasible?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-27-2025 01:01 PM
You just need to design the ACL to differentiate between contractors and the rest of the group based on roles, user attributes, or specific logic.
Sample Script:
(function executeRule() {
var allowedContractorGroup = ['Contractor Assignment Group Sys ID']; // Contractors' assignment group
var currentUserGroups = gs.getUser().getMyGroups(); // Get all groups of the user
var isContractor = false;
// Check if the user belongs to the contractor group
for (var i = 0; i < currentUserGroups.length; i++) {
if (allowedContractorGroup.indexOf(currentUserGroups[i]) !== -1) {
isContractor = true;
break;
}
}
// Restrict contractors to cases with Workplace Service = Package Delivery
if (isContractor) {
return current.workplace_service == 'Package Delivery';
}
// Allow non-contractors (internal users) to access all cases
return true;
})();
ɪꜰ ᴍʏ ᴀɴꜱᴡᴇʀ ʜᴀꜱ ʜᴇʟᴘᴇᴅ ᴡɪᴛʜ ʏᴏᴜʀ Qᴜᴇꜱᴛɪᴏɴ, ᴘʟᴇᴀꜱᴇ ᴍᴀʀᴋ ᴍʏ ᴀɴꜱᴡᴇʀ ᴀꜱ ᴛʜᴇ ᴀᴄᴄᴇᴘᴛᴇᴅ ꜱᴏʟᴜᴛɪᴏɴ ᴀɴᴅ ɢɪᴠᴇ ᴀ ᴛʜᴜᴍʙꜱ ᴜᴘ.
ʙᴇꜱᴛ ʀᴇɢᴀʀᴅꜱ
ꜱʀᴇᴇʀᴀᴍ
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-27-2025 02:43 PM
Thanks, I did create separate read/write ACLs based on the contractor role, but they're still able to access all of our cases, instead of just the handful being outlined in the business rule. I tried your script as well but no luck.