NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER, ACCENTURE.
DIFFICULTY LEVEL: Beginner
Assumes has good beginner level of knowledge and/or familiarity with ServiceNow and some familiarity with JavaScript.
There are several ways of limiting records to be displayed to the user. Of these there are three out-of-the-box (OOtB) that are most widely used:
- ACLs
- Data Policy
- Query Business Rule
Of the above I like the Query Business Rule (BR) as it gives a seamless user experience. With this article we will be exploring the Query BR, and how you can limit user access to data.
In this example I will give a couple of best practices:
- Requirements and Design gathering
- Role to Group Association
- Using a Query BR to Limit Data exposure
Requirements:
Our fictitious company Wigit-Inators would like to constrain all user access to widget Incidents. The desire is to limit these records to be viewed by only authorized personnel. This Widget Analyst would be allowed to see all incident records including Widget incident records. These records will also be those that include the word Wire (just to give us more to see). All other Itil users would be excluded from seeing Widget and Wire Incidents
1. Create a new Role: Widget Analyst
2. Limit access to widget records in the Incident table to be viewable only by those with the Widget Analyst role. Keep the other Itil user(s) from seeing Widget Incident records.
3. Only records with the word "wire" or "widget" will be affected.
4. ServiceNow admins will also have access
Design:
1. Create new role: widget_analyst
2. Create new group: Widget Analysts
3. Create new Query BR: Widget Exclude that:
a. Will allow only analysts with the widget_analyst role to see widget records.
b. The widget records will not be visible to those without the widget_analyst role.
c. Admins will be allowed to see widget records as well.
d. Widget Analysts will be able to see all other Incidents as well as widget records.
e. Widget Analysts and Admins will be able to see Incidents with the words "wire" or "widget in the short_description field. All other Itil users will not be able to see these incident records.
NOTE: Best Practice: Always assign roles to a group, then assign users to the group. Never assign roles directly to users. With roles it is much easier to maintain a group than individual users.
Lab 1.1 — Limiting Data Access With a Query BR
1. Create a new role
a. Navigate to User Administration -> Roles. The Roles list view will be displayed.
b. Click on the New button. The New Role form will be displayed.
c. Fill in the form with the following:
i. Name: widget_analyst
ii. Description: Persons who analyzes widgets
iii. Click the Submit button to save the new role.
2. Create a new group
a. Navigate to User Administration -> Groups. The Groups list view will be displayed.
b. Click on the New button. The New Group form will be displayed.
c. Fill in the form with the following:
i. Name: Widget Analysts
ii. Description: People with the Widget Analyst role
d. Right-click on the form header to bring up the form context menu. Click on the Save option to save your work.
e. Scroll to the bottom of the Group form and choose the Roles tab.
i. Click the Edit button. The Edit Members form will be displayed.
ii. Choose the Itil role. The users will need full access to all incidents.
iii. Choose the widget_analyst role. These users will be able to view the widget incident records.
iv. Click the Save button to save your work and return to the Group form.
v. You will see information messages displayed at the top of the form notifying you of the role assignments to the group.
f. Choose the Group Members tab.
i. Click the Edit button. The Edit Members form will be displayed.
ii. Choose your favorite user(s) that you want to be widget people.
iii. Click the Save button to save your work and return to the Group form.
iv. You will see information messages displayed at the top of the form notifying you of the role assignments now given to the users assigned to the group.
3. Create new Query BR
a. Navigate to System Definition -> Business Rules. The Business Rules list view will be displayed.
b. Click on the New button. The New Business Rule form will be displayed.
c. Fill in the form with the following:
i. Name: Widget Exclude
ii. Table: Incident
iii. Active: Checked
iv. Advanced: Checked
d. Click on the When To Run tab
i. When: before
ii. Order: 100
iii. Query: checked
e. Click on the Advanced tab
i. Condition: None.
ii. Script
(function executeRule(current, previous /*null when async*/) {
// Look for these words in the short descript and use it as a filter
// This script adds to the overall list view query that is used to display
// the list view
if (gs.hasRole("widget_analyst") || gs.hasRole("admin")) {
gs.addInfoMessage('---> Has the needed roles!');
var incidentInclusion = current.addOrCondition('short_description', 'CONTAINS', 'widget')
.addOrCondition('short_description', 'CONTAINS', 'wire');
}
else {
gs.addErrorMessage('---> Does NOT have the needed roles!');
var incidentExclusion = current.addQuery('short_description', 'DOES NOT CONTAIN', 'widget')
.addQuery('short_description', 'DOES NOT CONTAIN', 'wire');
}
})(current, previous);
f. Click on the Submit button to save your work.
We are done! Now let's test our new BR!
Lab 1.2 — Testing the Business Rule
NOTE: For more information on impersonating a user see this docs article.
1. Navigate to Incident -> Open. This will display a list view of open Incidents.
a. Edit the description field of two or three of these to include the word "widget", or "wire". These will be picked up by our new BR.
2. Navigate to User Administration -> Roles. The display view of roles will appear.
a. Filter for the Itil role
b. Click on the Itil role
c. Click on the Users tab - The users tab may not be on the form with an OOB instance. You will need to add the tab (Configure > Related Lists)
d. Observe a user who is not in your Widget Analyst group. I chose Bud Richman.
3. Impersonate one of the users in your Widget Analyst group and test for access.
a. Click on the impersonate button.
b. Pick your user. I chose Beth as she is Itil, and Widget Analyst
c. Navigate to Incident -> Open
d. If the Short Description field is not visible on the list view then personalize your list view to add it.
e. Filter on all records with the words "widget", or "wire".
f. Expected result: You should see these records in the list view, along with the message "Has the needed roles!" at the top of the form.
3. Impersonate one of the Itil users not in your Widget Analyst group and test for access.
a. Click on the impersonate button.
b. Pick your user. I chose Bud Richman as remember that he is not a Widget Analyst.
c. Navigate to Incident -> Open
d. Filter on all records with the words "widget", or "wire".
e. Expected result: No records should be displayed and the message: "Does NOT have the needed roles!" is displayed at the top of the form.
4. Change back to the Administrator and test for access.
a. End the impersonation.
b. Navigate to Incident -> Open
c. Filter on all records with the words "widget", or "wire".
d. Expected result: You should see these records in the list view. It should look exactly like Beth Anglin's:
And our testing is completed! Wigit-Inators LLP is ecstatic over the new functionality you have provided! 🙂
As you can see the user without access will not even be aware that records are being filtered. There is absolutely no indication on the list view. I really like that feature of Query BRs!
With a little thought you could refactor the BR script to be the following:
function onBefore(current, previous) {
// Look for these words in the short descript and use it as a filter
// This script adds to the overall list view query that is used to display
// the list view
if (!gs.hasRole("widget_analyst") && !gs.hasRole("admin")) {
gs.addErrorMessage('---> Does NOT have the needed roles!');
var incidentExclusion = current.addQuery('short_description', 'DOES NOT CONTAIN', 'widget')
.addQuery('short_description', 'DOES NOT CONTAIN', 'wire');
}
}
I will leave you to do the testing! 🙂
Enjoy!
Steven Bell.
If you find this article helps you, don't forget to log in and mark it as "Helpful"!
Originally published on: 10-20-2015 09:00 AM
I updated the code and brought the article into alignment with my new formatting standard.
7 Comments
