How to Restrict "Incident" Data to Specific 3rd Party Companies

Who is this tutorial for?

This tutorial is for users integrating multiple 3rd parties (e.g., multiple companies using Jira) with ServiceNow, and you want to ensure that each company only sees their relevant data.

Use Case

The examples here are based on the Incident type in ServiceNow. However, you can apply the same logic to other types like Change Request, Requested Item, Incident Task, etc.

If your ServiceNow instance is integrated with multiple 3rd party companies using Jira, this setup ensures that each company only sees the data associated with their Assignment Group in the Getint integration.

Important: When creating an Incident in ServiceNow, always specify the Assignment Group field.

How does it work?

Incident 1 created in ServiceNow with Assignment Group: company1 will result in Getint creating a Bug in company1's Jira.
Incident 2 created in ServiceNow with Assignment Group: company2 will result in Getint creating a Bug in company2's Jira.
Incident 3 created in ServiceNow without an Assignment Group will not create any Bug in Jira, even if the integration is enabled.

When a Bug is created in Jira by company1 or company2:

Getint automatically creates a corresponding Incident in ServiceNow with the appropriate Assignment Group matching the company (e.g., company1 or company2).

Quick Steps

Create an Assignment Group in ServiceNow (e.g., company1).
Create a user with the username company1 and assign the roles: getint, sn_incident_read, sn_incident_write.
Add Business Rules for incidents (and other relevant types) to restrict access (Insert, Update, Read) based on the Assignment Group and username.
Add Business Rules to ensure that each company only uses its own Assignment Group.

Step 1: Create an Assignment Group in ServiceNow

To ensure that each company only has access to its own Incidents and data, first create an Assignment Group in ServiceNow.

Go to User Administration > Groups.
Create a new Assignment Group.

Name the group (e.g., company1).

Step 2: Create a ServiceNow User for Each Company

For tutorial purposes, the Assignment Group name should match the username for the integration user. Of course, it is possible to use any assignment group but, in such case, scripts defined below will have to be adjusted.

Go to User Administration > Users and create a new user (e.g., company1).
Set the User ID to company1.
Set the password for the user.
Assign the roles: getint, sn_incident_read, sn_incident_write. If the getint role doesn’t exist, create it as described earlier.

Important note:

In this tutorial, we created the getint_integration user (and it applies for most cases where you have a single ServiceNow and single Jira to integrate), but we need to create another user (for each company) and assign roles: getint, sn_incident_read, sn_incident_write)

Step 3: Add a Business Rule to Restrict Access to Incidents by Assignment Group and Username

You need to create Business Rules to ensure that data visibility is restricted by Assignment Group and username.

Requirements:

The Assignment Group (e.g., company1) is created.
The user with the matching username (e.g., company1) and with the roles assigned: (getint, sn_incident_read, sn_incident_write

Important: The username and Assignment Group must be identical (case-sensitive).

Steps:

Go to Administration > Business Rule.
And follow the steps shown in the pictures below:

Create a new Business Rule with the following script:

(function executeRule(current, previous) {
    var userName = gs.getUserName();  // Get the current user's username

	// Bypass restriction for admin users
    if (gs.hasRole('admin')) {
        gs.info("Admin user, bypassing group restriction.");
        return; // Allow admins to proceed
    }

    // Handle querying incidents where assignment group matches the username
    if (!current.isNewRecord()) {  // Only add this condition for non-insert actions
        current.addQuery('assignment_group.name', userName);  // Compare assignment group's name with the username
        gs.info("Querying incidents where assignment group matches username: " + userName);
    }

    // Handle inserts - set the assignment group based on the username
    if (current.isNewRecord()) {  // If this is an insert operation
        var userGr = new GlideRecord('sys_user_group');
        userGr.addQuery('name', userName);  // Find the group by username
        userGr.query();
        
        if (userGr.next()) {
            current.assignment_group = userGr.sys_id;  // Set the assignment group to the group found
            gs.info("Set assignment group to: " + userGr.name + " for user: " + userName);
        } else {
            gs.error("No matching assignment group found for username: " + userName);
        }
    }

    // Handle updates - restrict changes if assignment_group doesn't match the username
    if (!current.isNewRecord() && current.assignment_group.changes()) {  // If it's an update and assignment_group has changed
        var newAssignmentGroup = current.assignment_group.getDisplayValue().toLowerCase();
        
        // Check if the new assignment group matches the current user's group
        if (newAssignmentGroup !== userName.toLowerCase()) {
            gs.addErrorMessage("You cannot change the assignment group to one that does not match your username.");
            gs.error("Update blocked: Attempt to change assignment group to: " + newAssignmentGroup + " by user: " + userName);
            current.setAbortAction(true);  // Prevent the update from completing
        }
    }
})(current, previous);

This script ensures that users only see Incidents assigned to their group, and it sets the Assignment Group automatically for new records.

Step 4: (Optional) Add Business Rule to Hide Other Assignment Groups

This step is optional and only serves to hide other Assignment Groups, ensuring that 3rd parties will only see their own Assignment Group (which matches their username) in the integration configuration.

Important: Even if a 3rd party company attempts to use an Assignment Group other than their own, Getint will ignore it and still enforce the use of the username as the Assignment Group.

Purpose:

This Business Rule ensures that each company only sees its own Assignment Group and hides others. This is useful for preventing 3rd parties from seeing Assignment Groups that do not belong to them.

Steps:

Go to Administration > Business Rule.
Create a new Business Rule following the steps shown in the images below.
Set the fields as shown in the image.

Script: In the Advanced tab, paste the following script to restrict the visibility of Assignment Groups based on the current user's username:

(function executeRule(current, previous /*null when async*/) {
    // Get the current user's username
    var userName = gs.getUserName();
    // Bypass restriction for admin users
    if (gs.hasRole('admin')) {
        gs.info("Admin user, bypassing group restriction.");
        return; // Allow admins to proceed
    }
    // Get the group name of the current group being queried or interacted with
    var groupName = current.name.getDisplayValue();
    // Log values for debugging (optional)
    gs.info("User: " + userName + " | Group: " + groupName);
	// Restrict the query to return only groups where the group name matches the username
    current.addQuery('name', userName);
})(current, previous);

This rule ensures that only the group matching the username will be visible to each company during the integration process.

Step 5: Add Business Rule to Restrict Access to Comments from Incidents

Steps:

Go to Administration > Business Rule.
And follow steps shown on the pictures below:

Create a new Business Rule with the following script

(function executeRule(current, previous /*null when async*/) {
	var username = gs.getUserName();

    // Filter records where the 'name' field is 'incident'
    current.addQuery('sys_class_name', 'incident'); // Ensure we are working with incidents only

    // Create a new GlideRecord for incidents
    var gr = new GlideRecord('incident');
    gr.addQuery('sys_class_name', 'incident'); // Ensure we are filtering incidents
    gr.query();

    var incidentSysIds = [];
    while (gr.next()) {
        var assignmentGroupId = gr.getValue('assignment_group'); // Get the sys_id of the assignment group
        var groupRecord = new GlideRecord('sys_user_group');
        if (groupRecord.get(assignmentGroupId)) { // Fetch group record
            var groupName = groupRecord.getValue('name'); // Get the group name
            if (groupName === username) {
                incidentSysIds.push(gr.getValue('sys_id')); // Add the incident's sys_id if it matches
            }
        }
    }

    // Now add the query to 'current' to return only the incidents with the collected sys_ids
    if (incidentSysIds.length > 0) {
        current.addQuery('element_id', 'IN', incidentSysIds); // Filter current to only include these sys_ids
    } else {
        current.addQuery('element_id', 'IN', ['-1']); // No matching incidents, return an empty set
    }

})(current, previous);

Step 6: Add Two Business Rules to Restrict Access to Attachments from Incidents

Steps:

Go to Administration > Business Rule.
And follow steps shown on the pictures below:

In the first step you will restrict access to the sys_attachment table, and in the second step you will restrict access to the sys_attachment_doc table (which holds the data for each attachment).

Restrict access to sys_attachment table

Create a new Business Rule with the following script

(function executeRule(current, previous /*null when async*/) {
    var username = gs.getUserName();

    // Filter attachments that are linked to incidents
    current.addQuery('table_name', 'incident'); // Filter only attachments related to incidents

    // Create a new GlideRecord to query incidents
    var gr = new GlideRecord('incident');
    gr.addQuery('sys_class_name', 'incident'); // Ensure we are filtering incidents
    gr.query();

    var incidentSysIds = [];
    while (gr.next()) {
        var assignmentGroupId = gr.getValue('assignment_group'); // Get the sys_id of the assignment group
        var groupRecord = new GlideRecord('sys_user_group');
        if (groupRecord.get(assignmentGroupId)) { // Fetch group record
            var groupName = groupRecord.getValue('name'); // Get the group name
            if (groupName === username) { // Compare assignment group with the username
                incidentSysIds.push(gr.getValue('sys_id')); // Add the incident's sys_id if it matches
            }
        }
    }

    // Now add the query to 'current' to return only the attachments linked to the incidents with the matching assignment group
    if (incidentSysIds.length > 0) {
        gs.error("Matching incident sys_ids: " + incidentSysIds.join(", "));
        current.addQuery('table_sys_id', 'IN', incidentSysIds); // Filter current to only include attachments linked to these incidents
    } else {
        gs.error("No matching incidents found for user: " + username);
        current.addQuery('table_sys_id', 'IN', ['-1']); // No matching incidents, return an empty set
    }

})(current, previous);

Restrict access to sys_attachment_doc table

Steps:

Go to Administration > Business Rule.
And follow steps shown on the pictures below:

Create a new Business Rule with the following script

(function executeRule(current, previous /*null when async*/) {
    var username = gs.getUserName();

    // Create a new GlideRecord for attachments related to incidents
    var attachmentGR = new GlideRecord('sys_attachment');
    attachmentGR.addQuery('table_name', 'incident'); // Filter for attachments related to incidents
    attachmentGR.query();

    var attachmentSysIds = [];
    while (attachmentGR.next()) {
        var incidentId = attachmentGR.getValue('table_sys_id'); // Get the sys_id of the related incident
        
        // Query the incident to get the assignment group
        var incidentGR = new GlideRecord('incident');
        if (incidentGR.get(incidentId)) {
            var assignmentGroupId = incidentGR.getValue('assignment_group'); // Get assignment group id
            var groupRecord = new GlideRecord('sys_user_group');
            if (groupRecord.get(assignmentGroupId)) { // Fetch group record
                var groupName = groupRecord.getValue('name'); // Get the group name
                if (groupName === username) {
                    attachmentSysIds.push(attachmentGR.getValue('sys_id')); // Add the attachment sys_id if it matches
                }
            }
        }
    }

    // Now add the query to 'current' to return only the documents linked to the attachments with the collected sys_ids
    if (attachmentSysIds.length > 0) {
        gs.error("Matching attachment sys_ids for user: " + username + " - " + attachmentSysIds.join(", "));
        current.addQuery('sys_attachment', 'IN', attachmentSysIds); // Filter current to only include attachment docs linked to these attachments
    } else {
        gs.error("No matching attachments found for user: " + username);
        current.addQuery('sys_attachment', 'IN', ['-1']); // No matching attachments, return an empty set
    }

})(current, previous);

Summary

We have now restricted data access for each company to the Incidents associated with their Assignment Group. You can apply similar logic to other tables, such as Change Request, to restrict full access.

If you need any further help or if you are experiencing issues with your integration, feel free to open a support ticket at our Support Portal.

PreviousCreating a Custom Field in ServiceNow NextHow to Restrict Access to Specific Tables for Integration

Last updated 3 months ago

Was this helpful?