Restricting record access

  • Release version: Australia
  • Updated March 12, 2026
  • 2 minutes to read
  • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    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 full answer 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.

    Warning:
    The customization described here was developed for use in specific instances, and is not supported by Now Support. This method is provided as-is and should be tested thoroughly before implementation. Post all questions and comments regarding this customization to our community forum.

    Consider the following example from a default business rule that limits access to incident records.

    Table 1. Default business rule limits access to incident records
    Name Table When
    incident query Incident before, query

    Restricting record access

    In the following example, users are restricted from accessing incident records unless they have the itil role and are listed in the Caller or Opened by field. When self-service users open a list of incidents, they can only see the incidents they submitted.
    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);}
    Note:
    You can also use access controls to restrict the records that users can see. For information, see Access Control List Rules.

    Schedule script for weekdays

    Type: Business Rules/Client Scripts.

    This script schedules the script for weekdays. Insert any script where it says "Your Script Here."
    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

    This script sets a date field depending on the current day of the week. In this example, if the day is Monday through Wednesday, it sets the date to this coming Monday; otherwise it sets the date field to next Monday.
    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 (System Definition > Validation Scripts). 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.

    Set the validation script's type to Date/Time. Then, with this validation script, if a user enters an incorrect format in a date/time field, they receive an error message.
    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.