Real Access Control Scenarios: Implementing Robust Security in Action

By /






Mastering Access Control in ServiceNow: A Deep Dive into Real-World Scenarios


Mastering Access Control in ServiceNow: A Deep Dive into Real-World Scenarios

In the intricate world of IT Service Management (ITSM), particularly within a platform as robust as ServiceNow, effective access control is paramount. It’s not just about preventing unauthorized access; it’s about ensuring the right people have the right permissions to do their jobs efficiently and securely. This article delves into practical, real-world scenarios related to access control in ServiceNow, drawing from common challenges and best practices encountered by professionals working with the platform.

We’ll explore how permissions are managed, from user and group roles to scripting complex access logic, and touch upon essential concepts like user delegation and the underlying table structures that govern these operations. Our focus is on providing clear, actionable insights that are not only technically accurate but also resonate with the day-to-day realities of ServiceNow administration and development.

Understanding the ServiceNow Access Control Landscape

ServiceNow’s security model is built on a foundation of roles, groups, and Access Control Lists (ACLs). Understanding these components is the first step to mastering access control. We’ll begin by laying the groundwork, covering fundamental aspects often discussed during technical interviews and critical for daily operations.

Current ServiceNow Version and Journey

It’s always good to be aware of the platform’s evolution. As of this writing, many organizations are actively working with the latest stable releases. Understanding the version progression helps in grasping the continuous enhancements and deprecations within the platform.

  • Current Version: Washington DC (latest stable release)
  • Previous Versions Worked With: Rome, San Diego, Tokyo, Utah, Vancouver. This journey highlights significant experience across multiple ServiceNow releases, showcasing adaptability and a deep understanding of the platform’s evolution.

Permissions: Users, Groups, and Best Practices

How do we grant users the ability to perform specific actions or access certain data within ServiceNow? The primary mechanism is through roles. Roles encapsulate a set of permissions that can be assigned to individual users or, more effectively, to groups.

  • Can we add permissions to users and groups? Absolutely. Permissions are primarily managed by assigning roles.
  • Best Practice: Assigning Roles via Groups. This is a critical best practice. Instead of assigning roles directly to individual users, which can become a management nightmare, assign roles to groups. When an employee joins, add them to the relevant groups. When they leave, simply remove them from those groups. This automates the removal of their permissions, significantly reducing the risk of orphaned access and simplifying lifecycle management. It’s a core tenet of efficient security administration.

Core Tables for User and Group Management

Behind the scenes, ServiceNow utilizes specific tables to store user and group information, along with their relationships.

  • User Table Name: The primary table for all user accounts is sys_user. This is where user credentials, profile information, and other user-specific data reside.
  • Group Member Table Name: The table that defines the relationship between users and groups is sys_user_grmember. Each record in this table links a specific user to a specific group, signifying membership.

Scripting User and Group Creation

While ServiceNow’s UI is powerful, automation through scripting is often necessary for bulk operations or integration. Here’s how you can create user and group records programmatically.

How to Create a User Account Using Script

Leveraging GlideRecord, you can programmatically create new user accounts. This is useful for onboarding processes or integrating with external HR systems.


var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Prepares a new record
userGr.username = 'jdoe'; // Sets the username
userGr.firstname = 'John'; // Sets the first name
userGr.lastName = 'Doe'; // Sets the last name
userGr.email = 'jdoe@example.com'; // Sets the email address
userGr.insert(); // Inserts the new record into the sys_user table

Troubleshooting Tip: Always ensure you are setting the mandatory fields for a user account, which typically include username, password (though often handled by authentication methods), and email.

How to Create a Group Using Script

Similarly, new groups can be created programmatically.


var newGr = new GlideRecord('sys_user_group');
newGr.initialize(); // Prepares a new record
newGr.name = 'IT Support - Level 1'; // Sets the group name
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Sets the manager's sys_id (replace with actual sys_id)
newGr.email = 'itsupport@example.com'; // Sets the group's email address
newGr.description = 'Handles initial IT support requests'; // Sets the group description
newGr.insert(); // Inserts the new record into the sys_user_group table

Note: The manager field expects a sys_id of a user. Ensure the provided sys_id is valid.

Scripting Permission Management

Adding roles to users or groups via script involves interacting with specific tables that manage these relationships.

How to Add Permissions (Roles) to User/Group Accounts Using Script

When a role is assigned to a user, a record is created in the sys_user_has_role table. For groups, it’s the sys_group_has_role table.

Adding a Role to a User:

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize(); // Prepares a new record
userRole.user = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the user
userRole.role = '2831a114c611228501d4ea6c309d626d'; // Sys_id of the role
userRole.insert(); // Creates the association
Adding a Role to a Group:

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize(); // Prepares a new record
grpRole.group = '477a05d153013010b846ddeeff7b1225'; // Sys_id of the group
grpRole.role = '2831a114c611228501d4ea6c309d626d'; // Sys_id of the role
grpRole.insert(); // Creates the association

Interview Relevance: Be ready to explain that you’re not directly modifying the user or group record but creating a link in a separate association table.

User Delegation: Enabling Collaboration and Continuity

User delegation is a powerful feature that allows one user to perform tasks on behalf of another. This is crucial for business continuity when employees are on leave or otherwise unavailable.

  • What exactly does user delegation mean in ServiceNow? It means granting another user the authority to act on your behalf within the ServiceNow platform. This typically includes the ability to approve records, receive notifications, and handle assignments that would normally be directed to the original user.
  • How does it work? A user can delegate their tasks by navigating to their user profile, scrolling down to the ‘Delegates’ related list, and specifying:
    • Delegate: The user who will act on their behalf.
    • Start Date & End Date: The period for which the delegation is active.
    • Permissions: Whether the delegate can handle assignments, notifications, or approvals.

Real-World Example: Imagine a manager who is the primary approver for expense reports. If they go on vacation, they can delegate their approval tasks to a senior team member. This ensures that expense reports can still be processed without delay, maintaining operational efficiency.

Managing Group Memberships Programmatically

Adding and removing users from groups is a common administrative task, often automated.

How to Add and Remove Group Members Using Script

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize(); // Prepare a new record
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the user to add
grMem.group = '477a05d153013010b846ddeeff7b1225'; // Sys_id of the group to add to
grMem.insert(); // Create the membership record
Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // Query for the specific user
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Query for the specific group
grMem.query(); // Execute the query

if (grMem.next()) { // If a matching record is found
    grMem.deleteRecord(); // Delete the membership record
}

Troubleshooting Tip: Ensure you have the correct sys_id for both the user and the group. If the record doesn’t exist, the removal script won’t find anything to delete.

Web Services Users: Dedicated for System Integration

In scenarios where external applications need to interact with ServiceNow programmatically, specialized user accounts are employed.

  • What is a web services user in a User account? A web services user is an account specifically created to allow third-party applications or services to connect to ServiceNow’s APIs. These users typically do not have the ability to log in to the ServiceNow graphical user interface (GUI) directly. Their sole purpose is to facilitate data exchange and integration.

Example: An HR system might use a web services user to push new employee data into ServiceNow automatically. This user account is granted specific roles that allow it to create or update user records but not to browse the platform.

Client-Side vs. Server-Side Operations

Understanding where code executes is crucial for writing efficient and secure ServiceNow solutions. ServiceNow distinguishes between client-side (browser-based) and server-side (platform-based) operations.

Accessing the Current User’s System ID

Retrieving the current logged-in user’s unique identifier (sys_id) is a common requirement for scripting.

  • How to get the current logged-in user’s system ID in the client-side? Use the global JavaScript object g_user: g_user.userID;
  • How to get the current logged-in user’s system ID in the server-side? Use the gs (GlideSystem) object: gs.getUserID();

Interview Tip: Be ready to explain why these are different. Client-side scripts run in the user’s browser, while server-side scripts run on the ServiceNow instance itself.

Checking Group Membership

Determining if the current user belongs to a specific group is a frequent need for conditional logic in both UI policies and business rules.

  • How to check if the current logged user is a member of a particular group or not? On the server-side, you can use: gs.getUser().isMemberOf('group name'); This method returns true if the user is a member and false otherwise.

Example: A business rule might check if the current user is a member of the ‘CAB Approval’ group before allowing an incident to be resolved without CAB review.

The Heart of Access Control: ACLs and Roles

Access Control Lists (ACLs) are the granular security rules that define who can access what and in what manner. Roles are the key to applying these ACLs effectively.

Required Role for Access Control Management

  • Which role is required to work on access control? The security_admin role is essential for creating, modifying, and managing ACLs. Users with this role have broad administrative access to the platform’s security configuration.

Impersonation: A Testing Essential

Impersonation is a critical feature for testing security configurations and user experiences.

  • What is impersonation? Impersonation allows an administrator to temporarily log in as another user. This is invaluable for verifying that a user has the correct permissions (or lack thereof) and to see the platform from their perspective. It’s a safe way to test security without needing to share user credentials.

Troubleshooting Tip: Always ensure you “stop impersonating” when you’re finished testing to avoid unintended actions or permissions.

Automating Workflows: Business Rules and Logic

Business rules are server-side scripts that run automatically when a record is displayed, inserted, updated, or deleted. They are fundamental for implementing complex automation and ensuring data integrity.

Scenario: Closing Parent and Child Incidents

A common requirement is to ensure that when a parent incident is closed, all its associated child incidents are also automatically closed.

  • Logic for closing parent and child incidents: This is best handled by an ‘after’ Business Rule on the incident table.
    • When to run: After Update
    • Condition: current.state.changesTo(7); (Assuming state 7 is ‘Closed’) AND current.parent == '' (to ensure it’s a parent incident being closed).
    • Script:
      
if (current.state == 7 && current.parent == '') {
    // GlideRecord to find child incidents
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Find incidents where the parent field matches the current incident's sys_id
    grChild.query(); // Execute the query

    while (grChild.next()) { // Iterate through each child incident found
        grChild.state = 7; // Set the state to Closed
        grChild.update(); // Update the child incident record
    }
}

Troubleshooting Tip: If child incidents aren’t closing, verify the state value for ‘Closed’ in your instance and ensure the ‘parent’ field is correctly populated on child incidents.

Scenario: Preventing Incident Closure with Open Tasks

To maintain data integrity and prevent premature closure, you might want to block the closure of an incident if associated tasks (incident tasks, problem tasks, change tasks) are still open.

  • Logic: Prevent closing incident with open tasks. This is implemented using a ‘before’ Business Rule on the incident table.
    • When to run: Before Update
    • Condition: current.state.changesTo(7); (Preventing closure)
    • Script:
      
// Check for open Incident Tasks
var grTask = new GlideRecord('incident_task');
grTask.addQuery('incident', current.sys_id);
grTask.addQuery('state', '!=', 3); // Assuming 3 is the state value for 'Closed' for incident tasks
grTask.query();

if (grTask.hasNext()) {
    gs.addErrorMessage('Cannot close the incident because there are open Incident Tasks.');
    current.setAbortAction(true); // Stops the update operation
}

// Check for open Problem Tasks (if relevant to your workflow)
var grProblemTask = new GlideRecord('problem_task');
grProblemTask.addQuery('problem', current.problem_id); // Assuming problem_id links incident to problem
grProblemTask.addQuery('state', '!=', 3); // Adjust state value if needed
grProblemTask.query();

if (grProblemTask.hasNext()) {
    gs.addErrorMessage('Cannot close the incident because there are open Problem Tasks associated.');
    current.setAbortAction(true);
}

// Check for open Change Tasks (if relevant to your workflow)
var grChangeTask = new GlideRecord('change_task');
grChangeTask.addQuery('change_request', current.change_request); // Assuming change_request links incident to change
grChangeTask.addQuery('state', '!=', 3); // Adjust state value if needed
grChangeTask.query();

if (grChangeTask.hasNext()) {
    gs.addErrorMessage('Cannot close the incident because there are open Change Tasks associated.');
    current.setAbortAction(true);
}

Troubleshooting Tip: The key here is current.setAbortAction(true);. If you don’t include this, the incident will still close. Ensure your state values for ‘Closed’ are correct across all related task tables.

Scenario: Closing Incidents When a Problem is Closed

When a root cause is identified and a problem record is resolved, it’s often desired that all related incidents stemming from that problem are also closed.

  • Logic: Closing associated incidents when a problem is closed. This is an ‘after’ Business Rule on the problem table.
    • When to run: After Update
    • Condition: current.state.changesTo(7); (Assuming state 7 is ‘Closed’)
    • Script:
      
if (current.state == 7) {
    // GlideRecord to find incidents associated with the problem
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Link incidents to this problem
    grIncident.addQuery('state', '!=', 7); // Only update incidents that are not already closed
    grIncident.query();

    while (grIncident.next()) {
        grIncident.state = 7; // Set the state to Closed
        grIncident.update(); // Update the incident
    }
}

Interview Relevance: This demonstrates understanding of relationships between tables (Incident to Problem) and the ability to automate cascading updates.

Deep Dive into ServiceNow Tables and Data Structures

Understanding ServiceNow’s data model is fundamental for effective configuration and development.

Out-of-the-Box vs. Custom Tables

  • What are some names of out-of-the-box tables? Out-of-the-box (OOTB) tables are those provided by ServiceNow and typically do not start with x_ or u_. Examples include incident, problem, change_request, cmdb_ci, sys_user, sys_group. Tables starting with x_ are usually created in scoped applications, and u_ was historically used for global custom tables (less common now with scoped apps).

Base Tables: The Foundation of Extensibility

  • What are some of the base tables? Base tables are foundational tables that are not extended by other tables but are extended by many. They provide common fields and functionality. Key examples include:
    • task: Provides common fields and functionality for all task-based tables (like Incidents, Problems, Changes).
    • cmdb_ci: The base table for all Configuration Items (CIs) in the Configuration Management Database (CMDB).

Examples of Task Tables

  • Give me some examples of task tables? These are tables that extend the task base table, inheriting its core fields. Common examples are:
    • incident
    • problem
    • change_request
    • sc_task (Service Catalog Task)
    • incident_task

Table Creation and Access Controls

  • Whenever we create a table, how many access controls will get created? By default, when you create a new table in ServiceNow, 4 Access Control Lists (ACLs) are automatically generated. These typically cover:
    • Read access for the general public (or role-less users, depending on configuration).
    • Create access for users with the itil role.
    • Write access for users with the itil role.
    • Delete access for users with the admin role.

    These are basic security policies. You can choose to uncheck the option to create these default ACLs during table creation if you plan to define custom ACLs from scratch.

Field Creation: Auto-Numbering

  • How to create a number field, like an incident number? For auto-generated numbers (like INC0001234), you need to configure the table’s control settings. When creating or configuring the table, you’ll find an “Auto-number” section. Here, you define:
    • Prefix: e.g., “INC”
    • Number of digits: e.g., 7
    • The system automatically generates sequential numbers, ensuring uniqueness.

Table Extension: Inheritance and the ‘Class’ Field

  • What happens when you extend a table? When you extend a table (e.g., creating incident from task):
    • Inheritance: The child table inherits all fields from the parent table. These inherited fields are not duplicated in the child table’s definition.
    • ‘Class’ Field: A field named class is created in the parent table (e.g., task). This field stores the sys_id of the actual table the record belongs to (e.g., the sys_id of the incident table for an incident record). This mechanism allows the platform to manage polymorphic behavior, where a single parent table can hold records from various child tables.

Common Field Types

ServiceNow offers a rich variety of field types to model data effectively.

  • Can you give me 10 field types?
    1. Reference (links to another record)
    2. String (text)
    3. List (multi-select reference)
    4. Choice (dropdown with predefined options)
    5. Email
    6. Date/Time
    7. Date
    8. Boolean (True/False)
    9. Integer (whole number)
    10. Journal (for free-form text, often with history)
    11. Attachment

Temporary vs. Normal Tables

  • What is the difference between a temporary and normal table?
    • Temporary Tables: These are typically used for staging data during import processes. They extend the import_set_row table and are designed for short-term data storage. Records in temporary tables are automatically purged after a set period (defaulting to 7 days) to manage storage and performance.
    • Normal Tables: These are standard tables that store data permanently until it’s explicitly deleted.
  • Can we increase the retention period in the temp table? Yes, you can adjust the retention period for temporary tables using archive rules or by configuring the system property that governs import set row cleanup.

Remote Tables vs. Normal Tables

  • What is the difference between a remote table and normal tables?
    • Remote Table: Data stored in a remote table is not actually stored within your ServiceNow instance. Instead, ServiceNow queries and displays data from an external source in real-time. This is achieved using features like ServiceNow’s REST Table API or JDBC Data Sources. It provides a live view of external data without consuming instance storage.
    • Normal Table: Data is stored directly within your ServiceNow instance’s database.

Table Relationships: One-to-One and One-to-Many

Understanding relationships is key to designing databases and applications.

  • What is one-to-one and one-to-many table in ServiceNow?
    • One-to-Many Relationship: A single record in one table can be related to multiple records in another table. The most common example is a User and Incidents relationship: one user can be assigned to many incidents, but each incident is typically assigned to only one user. This is implemented by adding a reference field in the “many” table pointing to the “one” table (e.g., an assigned_to reference field on the incident table pointing to sys_user).
    • One-to-One Relationship: A single record in one table can be related to at most one record in another table, and vice versa. This is less common and often achieved using specific field configurations or custom logic to enforce the constraint. It’s sometimes seen when you need to extend a table’s functionality without altering the original table directly.
    • Many-to-Many Relationship: Multiple records in one table can be related to multiple records in another table. A classic example is Incidents and Groups: an incident can be assigned to multiple support groups, and a group can be responsible for many incidents. This is typically implemented using a many-to-many table (a table with two reference fields, each linking to one of the primary tables). For example, the sys_user_group_has_role table links groups to roles, demonstrating a many-to-many concept between groups and roles. For incidents and groups, a custom table might be used, or a linking mechanism via features like “Watch List” or “Assignment Groups” which inherently handle many-to-many associations.

Ways to Create Records

  • In how many ways can we create a record in a ServiceNow table?
    1. Form: The standard UI way by filling out a form.
    2. Record Producer: A type of catalog item that creates a record on a table.
    3. Email: Incoming email processing can create records based on predefined rules.
    4. GlideRecord Script: Server-side scripting to insert records.
    5. Import Sets/Excel Sheet: Bulk data import using the import set functionality.
    6. External System: Via REST APIs or SOAP web services.

Mandatory and Read-Only Fields

Controlling field requirements and editability is crucial for data quality.

  • In how many ways can we make a field mandatory, read-only?
    1. Dictionary Entry: Setting the “Mandatory” or “Read only” attribute directly in the field’s dictionary definition.
    2. Dictionary Overrides: For child tables, overriding the parent field’s properties.
    3. UI Policies: Client-side scripts that make fields mandatory, read-only, visible, or hidden based on conditions when the form is loaded or interacted with.
    4. Data Policies: Server-side (and client-side) policies that enforce mandatory or read-only states, working across all data entry points.
    5. Client Scripts: Using g_form.setMandatory('field_name', true/false); or g_form.setReadOnly('field_name', true/false); on the client-side.
    6. Server Scripts: Using current.setMandatory('field_name', true/false); on the server-side (less common for making mandatory, more for validation).

Display Fields: The User-Facing Identifier

  • Can we make 2 fields as display in one table? No, only one field can be designated as the “Display” field for a table. This field is used in reference fields and list lookups to show a user-friendly value (like a name or number) instead of just the sys_id. Having more than one display field would lead to ambiguity and confusion.

System Table Storage

  • All tables will be stored where? All table definitions in ServiceNow are stored in the sys_db_object table. This is the meta-table that describes your database schema.

Setting Default Values

  • How to set a default value on a field? Default values are set in the field’s dictionary entry. When a new record is created, if the field is empty, it will be populated with this default value. This is useful for pre-filling fields with common values, saving users time and ensuring consistency.

Advanced Field and Form Customization

Beyond basic field types, ServiceNow offers sophisticated mechanisms for controlling data behavior and user interaction.

The ‘current’ Object: Server-Side Manipulation

  • What is the current object? The current object is a server-side JavaScript object that represents the record currently being processed by a script (e.g., in a Business Rule, Script Include). It allows you to get and set field values on that record.
  • How to set the field values on the current form (server-side)?
    • To set a value: current.setValue('field_name', value);. For reference fields, the value must be the sys_id of the referenced record.
    • To set a display value (for reference fields): current.setDisplayValue('field_name', value);. Here, you provide the human-readable value (e.g., the user’s name), and ServiceNow will find the corresponding sys_id.

Reference Qualifiers: Filtering Lookups

Reference qualifiers are essential for making reference fields more user-friendly and data-driven by limiting the options presented.

  • What is a reference qualifier, and what are its types? A reference qualifier is a condition applied to a reference or list field to filter the records that can be selected. This ensures users only see relevant options.
  • Types of Reference Qualifiers:
    • Simple: The most basic type. You define a direct filter condition using field comparisons.

      • Description: Filters based on static conditions.
      • Example: To show only active users in a reference field, you’d use active=true.
      • How to Use: In the field’s dictionary entry, under “Reference Specification,” define the conditions in the “Reference qual” field.
    • Dynamic: Uses a dynamically generated query based on context.

      • Description: Allows filtering based on values of other fields on the current form or session context.
      • Example: Displaying only incidents assigned to the current user’s assignment group.
      • How to Use: You create a “Dynamic Filter Option” (System Definition > Dynamic Filter Options) and then select it in the “Reference qual” field.
    • Advanced (JavaScript): The most flexible type, using JavaScript to construct the filter.

      • Description: Enables complex filtering logic using JavaScript, offering maximum control.
      • Example: Filtering incidents to show only those with a priority less than 3 AND assigned to the current user’s group. The script would look something like: javascript: 'assignment_group=' + g_user.getMyGroups() + '^priority<3'; (Note: Actual script might vary based on how getMyGroups() is implemented or if you use a Script Include). A more direct example often seen is: javascript: 'active=true^company='+current.company;
      • How to Use: Select “Advanced” in the “Reference qual” field and enter your JavaScript code. This code typically returns a query string.
  • Difference between types:
    • Simple vs. Dynamic: Simple is static. Dynamic adapts based on context defined via Dynamic Filter Options.
    • Dynamic vs. Advanced: Dynamic uses pre-defined filter options. Advanced allows custom JavaScript for highly complex, on-the-fly logic that might not be covered by dynamic filters.
    • Simple vs. Advanced: Simple is a basic query string. Advanced offers the full power of JavaScript for intricate filtering.

Dependent Values: Cascading Dropdowns

  • What is dependent value? Dependent values (or dependent fields) create a cascading effect in dropdowns (Choice fields). The options available in one field (the dependent field) are filtered based on the selection made in another field (the parent field).
  • Example: A common example is the Category and Subcategory relationship on the Incident form. If the Category is “Hardware,” the Subcategory dropdown will only show options like “Laptop,” “Desktop,” “Printer.” If the Category is “Software,” it might show “Operating System,” “Application,” “Database.”
  • Configuration: This is set in the dictionary entry of the dependent field by specifying the “Dependent Field” attribute, linking it to the parent field. Each choice for the dependent field is then associated with a specific value from the parent field.

Calculated Values: Deriving Field Data

  • What is a calculated value? When a field’s value needs to be automatically derived from other fields on the same record, you can use a calculated field. This is configured in the field’s dictionary entry by providing a JavaScript expression.
  • Example: On an Incident, if you have fields for “Impact,” “Urgency,” and “Priority,” you might have a “Priority” field whose value is calculated based on the selections of Impact and Urgency. The calculation logic is written in the “Calculated value” script in the Priority field’s dictionary.

Attributes: Field Behavior Modifiers

  • What are attributes, and name some used ones? Attributes are special parameters applied to fields (in their dictionary entries) or collections (tables) to modify their behavior or appearance. They are key-value pairs.
    • no_email: Prevents email notifications from being sent for changes to this field.
    • no_attachment: Disables the attachment functionality for this field.
    • no_add_me: Used on list collector fields to disable the “Add Me” button.
    • tree_picker: Enables a tree-like selection interface for reference fields.
    • ref_ac_columns: Specifies which columns to display in the reference lookup popup.
    • ref_auto_completer=AJAXTableCompleter: Enables auto-completion for reference fields.
  • How to enable/disable attachment on the form using attributes? You apply the no_attachment attribute to the collection field (the table itself) in its dictionary entry. This disables attachments for all records of that table.

Dictionary Overrides: Child Table Customizations

  • What are dictionary overrides? What properties can be overridden? A dictionary override allows you to change the definition of a field that exists in a parent table, but only for a specific child table. This is crucial for tailoring inherited fields. You can override virtually any property of a field, including:
    • Default value
    • Mandatory status
    • Read-only status
    • Max length
    • Display status
    • Reference qualifier
    • Choice list
    • Attributes
    • Labels
  • Example: The task table might have a default priority of 4. In the incident table (which extends task), you can create a dictionary override to change the default priority to 5.

User Interface and Experience Customization

ServiceNow provides powerful tools to tailor the user interface to meet specific business needs and improve user experience.

Application Menus and Modules: Navigating the Platform

  • What are application menus? Application menus are the top-level navigation items that appear in the left-hand navigator. They group related modules. Modules are the actual links to lists, forms, or reports within an application menu. Together, application menus and modules provide the primary way users access functionality and data within ServiceNow.

Process Flow: Visualizing Workflow Stages

  • What is process flow? Process flow is a visual indicator that shows the current stage or state of a record within a defined workflow. It often appears as a series of stages displayed horizontally across the top of a form, highlighting the active step and preceding/succeeding stages. This helps users quickly understand where a record is in its lifecycle and what the next steps might be.

Data Lookup Rules: Automatic Field Population

  • What are data lookup rules? Data lookup rules are a mechanism to automatically populate field values on a record based on the values of other fields on the same form. They are configured in a separate table (sys_data_lookup_rule) and are highly efficient for populating fields based on predefined relationships without requiring complex scripting.
  • Example: If you select a specific “Configuration Item,” a data lookup rule could automatically populate the “Affected User” field based on who is assigned to that CI.

UI Policies: Client-Side Form Control

UI policies are a client-side scripting alternative that allows administrators to dynamically change form behavior without writing complex JavaScript.

  • What are UI policies? UI policies are server-side configurations that run on the client-side to make fields mandatory, read-only, visible, or hidden, and to set field values, based on specific conditions. They are evaluated when the form loads and can also be triggered by user interactions.
  • Global Checkbox: If checked, the UI policy applies to all views of the form. If unchecked, you specify a particular view where it should apply.
  • Reverse if False: When checked, if the UI policy’s conditions are not met (evaluate to false), the actions defined in the UI policy will be reversed. For example, if a field was made read-only when the condition was true, it would become editable again when the condition is false.
  • On Load Checkbox: If checked, the UI policy’s conditions and actions are evaluated when the form is initially loaded. If unchecked, the UI policy’s actions are only triggered by user interaction with form fields or other events.
  • Inherit Checkbox: When checked, the UI policy will also be applied to child tables that extend the table on which the UI policy is defined. This is a powerful way to enforce consistent form behavior across related tables.
  • Can you write script in UI policy? Yes, you can write client-side scripts within UI policies. You need to enable the “Run scripts” checkbox in the UI policy action, which then allows you to define “Script” fields for when the condition is true and when it’s false.

Converting UI Policies to Data Policies

  • Can we convert UI policy as data policy? Yes, ServiceNow provides a convenient feature to convert UI policies into data policies.
  • Cases where conversion is NOT ideal: A UI policy is primarily for client-side interaction and visual changes. It cannot be directly converted into a data policy if it:
    • Controls data visibility (e.g., making a field visible/hidden).
    • Controls views.
    • Controls related lists.
    • Relies heavily on client-side scripting that directly manipulates the DOM or has complex client-side only logic not directly translatable to data policy actions.

    Data policies are focused on data consistency and integrity across all access points (client and server).

Data Policies: Server- and Client-Side Data Enforcement

  • What are data policies? Data policies are a more robust mechanism for enforcing data consistency and integrity. They can make fields mandatory, read-only, or visible/hidden, and they operate on both the client-side (for immediate user feedback) and the server-side (ensuring enforcement regardless of how the data is entered). This makes them ideal for enforcing critical business rules.

Conclusion

Mastering access control in ServiceNow is a continuous journey. It involves understanding the platform’s core security constructs like roles and ACLs, leveraging scripting for automation, and utilizing declarative tools like UI policies and data policies to manage user experience and data integrity. The scenarios discussed here represent common challenges and solutions that administrators and developers encounter daily. By internalizing these concepts, you’ll not only be better prepared for technical interviews but also more effective in building secure, efficient, and user-friendly ServiceNow solutions.


Scroll to Top