Restricting record access
Summarize
Summary of Restricting record access
This content explains how to restrict user access to records in ServiceNow using query business rules that run before database queries. It highlights a common use case where users can only see records they are authorized for, such as incident records limited to those with the itil role or where the user is the caller or opened by. It also contrasts this approach with Access Control Lists (ACLs) as an alternative for record restriction.
Show less
Key Features
- Query Business Rule for Record Restriction: A business rule example restricts incident records so that only users with the itil role or those listed in the Caller, Opened by, or Watch list fields can access them.
- Warning on Support and Testing: This customization is unsupported by Now Support and should be thoroughly tested before deployment. Community forums are recommended for discussions.
- Scheduling Scripts on Weekdays: A script template is provided to execute logic only on weekdays, useful for scheduling automated tasks.
- Date Field Setting Based on Day of Week: A script example shows how to set a date field to the upcoming Monday or the next Monday depending on the current day, demonstrating practical date manipulation.
- Date/Time Field Validation: Instructions for creating a validation script to ensure user input matches the instance’s date/time format. The script returns an error for invalid formats and requires maintenance if the instance date/time format changes.
Practical Implications for ServiceNow Customers
By implementing query business rules as shown, customers can enforce fine-grained record access restrictions beyond standard ACLs, improving data security and ensuring users see only relevant records. The scheduling and date-setting scripts provide templates for automating date-sensitive logic, enhancing workflow automation. The date/time validation script helps maintain data integrity by preventing incorrectly formatted user inputs.
Customers should thoroughly test these scripts in their environments due to their unsupported status and potential impact on performance and user experience. Leveraging community forums for support and updates is recommended.
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.