Restricting record access
Summarize
Summary of Restricting Record Access
This guide provides methods for restricting user access to specific records in ServiceNow through the use of query business rules. These customizations are intended for specific scenarios and are not officially supported, so thorough testing is essential before implementation.
Show less
Key Features
- Query Business Rule: Prevents users from accessing certain incident records unless they possess the itil role or are listed in specific fields (Caller or Opened by).
- Access Control: Access controls can also be utilized for restricting record visibility.
- Weekday Scheduling Script: This script allows scheduling of actions only on weekdays, preventing execution on weekends.
- Date Field Adjustment Script: Adjusts a date field based on the current day of the week, setting it to the next Monday depending on the day.
- Date/Time Validation Script: Validates user input in date/time fields to ensure correct format, providing feedback on errors.
Key Outcomes
By implementing these scripts, customers can effectively manage record access based on user roles, schedule operations flexibly, and ensure data integrity in date/time fields. This leads to improved security, operational efficiency, and user experience within the ServiceNow platform.
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;}For more information, see Validation script use case - Date and time.