Restricting record access
Summarize
Summary of Restricting Record Access
This document outlines methods for restricting access to records in ServiceNow using query business rules and validation scripts. It provides examples and cautions regarding implementation, emphasizing the need for thorough testing and community support for customization queries.
Show less
Key Features
- Query Business Rule: This feature allows you to prevent users from accessing specific records by executing a query before the database query. For example, incident records can be restricted to users with the 'itil' role or those listed in the Caller or Opened by fields.
- Access Controls: In addition to query business rules, access controls can be used to manage record visibility for users.
- Validation Scripts: Validation scripts ensure that date/time fields are entered in the correct format, providing feedback to users when incorrect formats are used.
Key Outcomes
By implementing these methods, ServiceNow customers can:
- Control user access to sensitive records, enhancing data security and compliance.
- Automate date field management based on the current day of the week, improving workflow efficiency.
- Ensure accurate user input for date/time fields, reducing errors and improving data integrity.
Always ensure that any customization is thoroughly tested before deployment and utilize the community forum for additional support and guidance.
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.