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:
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.
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)
If you need any further help or if you are experiencing issues with your integration, feel free to open a support ticket at our
