Restricting record access
Summarize
Summary of Restricting record access
This content explains how to restrict access to records in ServiceNow using query business rules that execute before database queries. It highlights a method to limit user access to certain records, such as incident records, based on roles and user association with the record fields. The guidance includes a caution that this customization is provided as-is, is not officially supported by Now Support, and should be thoroughly tested before use.
Show less
Key Features
- Query Business Rule for Record Restriction: You can create a business rule that runs before the query and filters records so users only see those relevant to them. For example, restricting incident access to users with the itil role or users listed in caller, opened by, or watch list fields.
- Example Script: The provided script checks if the user lacks the itil role and is accessing interactively, then restricts the query to incidents associated with the user.
- Alternative Access Controls: Access Control List (ACL) rules can also be used to restrict record visibility, offering another layer of security.
- Supplementary Scripts: Additional example scripts demonstrate scheduling execution on weekdays only and setting date fields dynamically based on the day of the week, showcasing practical scripting techniques relevant to record management.
- Date/Time Validation Script: A validation script example ensures that date/time inputs conform to the instance’s date/time format, providing error messages for incorrect inputs. This script should be configured under System Definition > Validation Scripts with the type set to Date/Time.
Practical Application for ServiceNow Customers
By implementing a query business rule as described, ServiceNow customers can tightly control which records users can access, enhancing data security and compliance within their instance. This is especially useful for scenarios where users should only view records they own or are involved with, such as incidents they created or are assigned to. Customers should test these customizations carefully in their environments to ensure expected behavior.
In addition, the included scripting examples for scheduling logic and date field handling provide templates for common automation needs, improving data accuracy and operational efficiency.
Finally, enforcing proper date/time input validation helps maintain data integrity and user input consistency, reducing errors caused by incorrect formatting.
You can use a query business rule that executes before the database query to prevent users from accessing certain records.
Consider the following example from a default business rule that limits access to incident records.
| Name | Table | When |
|---|---|---|
| incident query | Incident | before, query |
Restricting record access
if (!gs.hasRole("itil")&& gs.isInteractive()) {
var u = gs.getUserID();
var qc = current.addQuery("caller_id", u).addOrCondition("opened_by", u).addOrCondition("watch_list","CONTAINS", u);
gs.print("query restricted to user: " + u);}Schedule script for weekdays
Type: Business Rules/Client Scripts.
var go ='false';
var now =new Date();
// Correct time zone, which is by default GMT -7
now.setHours(now.getHours()+8);
var day = now.getDay();
// No go on Saturday or Sunday
if(day !=0&& day !=6){
// (your script here)
}Set date field according to current date
function setCabDate(){
var today = new Date();
var thisDay = today.getDay();
//returns 0 for Sunday, 1 for Monday, through 6 for Saturday.
var thisMon = new GlideDateTime();
thisMon.setDisplayValue(gs.beginningOfThisWeek());
var nextMon = thisMon.getNumericValue();
nextMon +=(1000*60*60*24*7);
if((thisDay <4)&&(thisDay >0))
//if today is Mon thru Wed (thisDay = 1, 2, or 3), set cab to this coming Monday.
current.u_req_cab_rev_date.setDateNumericValue(thisMon.getNumericValue());
else if((thisDay >=4)||(thisDay ==0))
//if today is Thurs thru Sun (thisDay = 4, 5, 6, or 0), set cab to next Monday.
current.u_req_cab_rev_date.setDateNumericValue(nextMon);
}To validate the input of all date/time fields, you can use the following in a validation script (). Because the date/time format is hard coded in this script, it must match your instance's date/time format. If your instance's date/time format changes, you must update your validation script.
function validate(value){
// empty fields are still valid dates
if(!value)
return true;
// We "should" have the global date format defined always defined. But there's always that edge case.
if(typeof g_user_date_time_format !=='undefined')
return isDate(value, g_user_date_time_format);
// if we don't have that defined, we can always try guessing
return parseDate(value)!==null;}