Lock down table records based on Groups

[AnthonyMull]

Hi Community,

I have a particular use case where we have many different teams working in service now but each team should only see, tasks, Changes, Problems , incidents etc for their particular assignment group.

what is the best way to implement these requirements?

Thanks for help.

[John Dahl]

1. Create an ACL to check the user's group membership. If the user is a member of the assignment group, allow access. Make sure you do not prevent a user from viewing their own tickets... for example, I can see incidents for which I am the caller.

2. Create a query BR to apply the same logic so that the user does not see the "XXX records removed by security constraint." message.

You should create both, even though they appear to do the same thing. The ACL is auditable where the BR improves UX. If you make auditors scour through all the BRs, then you're asking for a headache!

[sreeram_nair · Accepted solution]

To ensure that each team in ServiceNow only sees tasks, changes, problems, incidents, etc., relevant to their assignment group, you can use Access Control Rules (ACLs) in conjunction with query business rules or domain separation (if applicable). Here's the best way to implement this requirement:

Use Access Control Rules (ACLs)

• Objective: Ensure that users can only access records associated with their assignment group.
• Steps:
  a. Navigate to System Security > Access Control (ACL).
  b. Create or modify ACLs for tables like Incident, Change, Problem, and Task.
  c. Use conditions to restrict access based on the Assignment Group field.
  d. Example ACL script:
  javascript

(gs.hasRole('itil') && gs.getUser().isMemberOf(current.assignment_group))​

This ensures that only users with the required role who belong to the assignment group can access the record.

---

2. Leverage Query Business Rules

• Objective: Restrict visibility of records by filtering them based on the user’s assignment group.
• Steps:
  a. Navigate to System Definition > Business Rules.
  b. Create a before query business rule for each relevant table (e.g., Incident, Problem, Change, etc.).
  c. Use a script to filter records based on the user’s assignment group:
  javascript

if (!gs.hasRole('admin')) {
    var groups = gs.getUser().getMyGroups(); // Get user's groups
    current.addQuery('assignment_group', 'IN', groups);
}

This will restrict the query to show only records assigned to the user's groups.

---

3. Domain Separation (If Applicable)

• Objective: For large organizations with multiple independent teams, domain separation can provide stricter separation of records.
• Steps:
  a. Enable Domain Separation in the instance.
  b. Associate assignment groups and users with specific domains.
  c. Configure domain-specific data visibility.
• Consideration: Use this only if the teams work in completely separate contexts with no overlap.

---

4. Assign Roles and Configure UI Policies

• Assign roles like itil, task_user, or custom roles to restrict access to specific tables and modules.
• Use UI policies or client scripts to further control what fields or forms users can interact with.

---

5. Use Workflows and Catalog for Assignment Automation

• Configure workflows to ensure tasks are auto-assigned to appropriate groups.
• Use Service Catalog items to ensure users submit tasks categorized by group.

---

6. Testing

• Test the configuration using user impersonation to ensure each team only sees their respective records.
• Verify behavior across different tables and modules.