Skip to main content

Developer interview questions

Okay, here are the questions and answers from the provided transcript about ServiceNow Developer interview questions:

Question 1: What is the difference between UI Policy and Data Policy?

Answer:

  • UI Policy:

    • Executes on the client-side.
    • Executes within the browser.
    • Used to control the user interface behavior on forms within the browser.
    • Can make fields mandatory, optional, read-only, writable, visible, or invisible for users interacting through the browser form.
    • Cannot hide fields.

  • Data Policy:

    • Executes on the server-side.
    • Runs from the server.
    • Enforces data consistency and integrity when records are created or updated from various sources, including:
      • REST and SOAP integrations
      • Third-party integrations
      • List views
      • Background scripts
      • Import sets
    • Used to make fields mandatory or optional and read-only or writable at the server level.
    • Cannot hide fields.

  • Can we convert UI Policy to Data Policy? Yes.

  • Why convert? To enforce the same conditions defined in a UI Policy on the server-side as well. For example, if a UI Policy makes "Resolution Code" and "Resolution Notes" mandatory when the "State" field changes to "Resolved", you can convert this UI Policy to a Data Policy to ensure these fields are also mandatory when records are updated via integrations or other server-side processes.

  • What happens upon conversion? The original UI Policy record becomes inactive, and a corresponding Data Policy record is created and becomes active.

Question 2: What are Client Scripts and types of Client Scripts?

Answer:

  • Client Script: Primarily used to change the behavior of forms in ServiceNow. They provide a way to add dynamic behavior to forms that is not achievable with UI Policies alone.
  • Types of Client Scripts in ServiceNow:
    • onLoad: Executes when a form is loaded.
    • onSubmit: Executes when a form is submitted.
    • onChange: Executes when the value of a field changes.
    • onCellEdit: Executes when a cell in a list is edited.

Question 3: Can we use onLoad client script in onChange?

Answer: Yes, you can use onLoad client script logic within an onChange client script. You can achieve this by using the isLoading parameter available in onChange client scripts. The isLoading parameter is a boolean that is true when the onChange script is triggered during the initial form load (when onLoad scripts are also running) and false when the onChange script is triggered due to a user changing a field value. By checking the isLoading parameter, you can conditionally execute onLoad script logic within your onChange script.

Question 4: What are the parameters in onChange Client Scripts?

Answer: There are five parameters available in onChange client scripts:

  • newValue: The new value of the field that triggered the onChange script.
  • oldValue: The previous value of the field that triggered the onChange script.
  • isLoading: A boolean value indicating if the onChange script is running during form load (true) or due to user interaction (false).
  • isTemplate: A boolean value indicating if the field value change was due to applying a template.
  • control: The GlideForm control object for the field that triggered the onChange script. This allows you to access and manipulate the field's properties.

Question 5: What is Dictionary Overrides?

Answer:

  • Dictionary Override: A property in ServiceNow that allows you to modify the default behavior of fields inherited from a parent table in child tables (like extending tables such as Incident, Problem, and Change from the Task table).
  • Purpose: To customize field properties in child tables without affecting the parent table's definition. This is useful when you want to change the default behavior of a field for specific record types (e.g., make a field mandatory in Incident but not in Problem, even if it's mandatory in the parent Task table).
  • Implementation: In a dictionary entry record for a field, you can find a "Dictionary Overrides" related list or tab. By creating a new dictionary override, you can specify which properties you want to override for a particular child table.
  • Overridable Properties: You can override properties like:
    • Default value
    • Mandatory status
    • Read-only status
    • Display properties (although you cannot hide fields using dictionary overrides)

Question 6: What is Business Rule and types of Business Rules?

Answer:

  • Business Rule: Server-side scripts in ServiceNow that execute database operations (CRUD - Create, Read, Update, Delete) and enforce business logic. They are triggered by database operations on records.
  • Types of Business Rules in ServiceNow:
    • Before: Executes before a record is inserted, updated, or deleted in the database. Commonly used for data validation, setting field values before saving, and preventing operations.
    • After: Executes after a record is inserted, updated, or deleted in the database. Commonly used for actions that need to happen after data is saved, such as sending notifications, updating related records, or triggering events.
    • Async (Asynchronous): Executes after a record is inserted, updated, or deleted, but in the background, without blocking the user's transaction. Ideal for long-running processes like sending email notifications, calculating SLAs, or complex backend tasks. Async Business Rules can also be scheduled.
    • Display: Executes before a form is displayed to the user. Primarily used to pass data from the server to the client-side using the g_scratchpad object.

Question 7: What is the importance of Display Business Rule?

Answer:

  • Importance of Display Business Rule: Primarily used to make server-side data accessible to client-side scripts (like Client Scripts or UI Policies) when that data is not directly available on the form itself.
  • Mechanism: It uses the g_scratchpad object. This is a JavaScript object available in Display Business Rules and Client Scripts.
  • How it works:
    1. In the Display Business Rule, you set properties on the g_scratchpad object and assign values to them. For example: g_scratchpad.variable_name = value;
    2. These g_scratchpad variables become available in Client Scripts (onLoad, onChange, etc.) running on the same form.
    3. Client Scripts can then access the values stored in the g_scratchpad to dynamically control form behavior or display information.
  • Syntax: g_scratchpad.variable_name = value;
  • Use Case: Fetching data from related tables or performing server-side calculations and making the result available to client-side scripts for form manipulation or display logic.

Question 8: Could you explain all the types of Business Rule?

Answer: (Detailed explanation of Before, After, Async, and Display Business Rules as already provided in Question 6).

Question 9: Can we call Business Rule in Client Side?

Answer: Yes, in a limited way. You can call a Display Business Rule from the client-side. Display Business Rules are specifically designed to make server-side data available to the client-side using g_scratchpad. However, you cannot directly execute other types of Business Rules (Before, After, Async) from the client-side. For more complex server-side logic calls from the client, you would use GlideAjax.

Question 10: What about Query Business Rule?

Answer:

  • Query Business Rule: A type of Business Rule that executes when a user queries a table to retrieve records. It operates during the data retrieval process.
  • Purpose: Primarily used for security and access control at the query level. It allows you to:
    • Enforce record-level security beyond standard ACLs.
    • Filter query results based on user roles, group membership, or other context.
    • Prevent users from seeing records they are not authorized to access even if they have table-level read access.
  • Functionality: When a query is executed against a table, the Query Business Rule checks conditions and can:
    • Add query conditions: Dynamically modify the query to restrict the results based on the user's context.
    • Abort the query: Prevent the query from executing if the user doesn't have the necessary permissions.
    • Example: Restricting access to Incident records based on the caller's department or location.

Question 11: What are all operations we do with Business Rule?

Answer: Business Rules can be triggered by the following database operations (CRUD operations):

  • Insert: When a new record is created.
  • Update: When an existing record is modified.
  • Delete: When a record is deleted.
  • Query: When records are being retrieved from the database (specifically for Query Business Rules).

Question 12: How many ways to trigger email notifications?

Answer: There are three main ways to trigger email notifications in ServiceNow:

  1. Workflow: Notifications can be configured within workflows to be triggered at specific points in the workflow process.
  2. Directly Configured Notifications: You can directly configure notifications to be triggered based on events (like record insert, update, etc.) on a table, using the Notification module.
  3. Event: You can trigger notifications based on system events. Events are raised by Business Rules, scripts, or other ServiceNow processes, and notifications can be subscribed to these events.

Question 13: Can we send email notification via Business Rule? If yes, then tell me how to send email notification by a Business Rule.

Answer: Yes, you can send email notifications via Business Rules.

How to send email notification via Business Rule:

You use the gs.eventQueue() method in a Business Rule to generate an event. This event can then trigger a notification that is configured to listen for that specific event.

Syntax:

gs.eventQueue(eventName, current, param1, param2);
  • eventName: A string representing the unique name of the event you are raising. This name needs to match the event name configured in the Event Registry and the Notification record.
  • current: The current GlideRecord object representing the record that triggered the Business Rule. This is often used to pass record-specific data to the notification.
  • param1 (optional): An optional parameter. Commonly used to pass the recipient's email address.
  • param2 (optional): Another optional parameter. Can be used for additional information, or another recipient address.

Important: After using gs.eventQueue(), you need to configure a Notification record that is triggered "When to send" is set to "Event is fired" and specifies the same eventName you used in gs.eventQueue(). In the Notification record, you can then use # tags to access param1 and param2 (if used) to populate recipient fields dynamically. You also need to enable "Param 1 contains recipient" and/or "Param 2 contains recipient" checkboxes in the Notification record if you are passing recipient addresses in param1 or param2.

Question 14: How do you send email notifications via Event?

Answer: To send email notifications via events, you need to follow these steps:

  1. Event Registry: Create an Event Registry record (System Policy > Events > Registry). In the Event Registry, define:

    • Name: A unique name for your event (e.g., incident.priority.updated).
    • Table: The table the event relates to (e.g., Incident).
    • Description: A description of the event.
    • Queue: Typically email.
    • Fired by: Indicate where the event will be fired from (e.g., Business Rule).

  2. Email Notification: Create an Email Notification record (System Policy > Email > Notifications). Configure:

    • Table: The same table as in the Event Registry (e.g., Incident).
    • When to send: Set to "Event is fired".
    • Event name: Select the event name you registered in the Event Registry (e.g., incident.priority.updated).
    • Who will receive: Configure recipients (Users, Groups, etc.). You can dynamically populate recipients using #param1, #param2 from the event, if applicable, and enable "Param 1 contains recipient" and "Param 2 contains recipient" if you are passing email addresses in the event parameters.
    • What it will contain: Define the subject and body of the email notification.

  3. Trigger Event (Business Rule or UI Action): In a Business Rule, UI Action, or other server-side script, use gs.eventQueue() to fire the event you registered. (Syntax and explanation of gs.eventQueue() as in Question 13).

Question 15: How do you send email notification in CC and BCC?

Answer: You can add CC and BCC recipients to an email notification programmatically using the GlideEmailOutbound API. You would typically use this within a Business Rule or Script Include.

Syntax (example within a Business Rule):

var email = new GlideEmailOutbound();
email.setSubject('Subject of the Email');
email.setBody('Body of the Email');
email.addAddress("to", current.caller_id.email, current.caller_id.name); // To recipient
email.addCC("cc_email_address_1@example.com"); // CC recipient
email.addBCC("bcc_email_address_1@example.com"); // BCC recipient
email.send();
  • GlideEmailOutbound(): Creates a new GlideEmailOutbound object to construct the email.
  • setSubject(): Sets the email subject.
  • setBody(): Sets the email body.
  • addAddress("to", recipient_email, recipient_name): Adds a "To" recipient.
  • addCC("cc_email_address"): Adds a CC recipient.
  • addBCC("bcc_email_address"): Adds a BCC recipient.
  • send(): Sends the email.

Question 16: What is Glide Record and use of it?

Answer:

  • Glide Record: A server-side JavaScript API in ServiceNow that allows you to interact with the ServiceNow database. It provides a way to perform CRUD (Create, Read, Update, Delete) operations on ServiceNow tables without writing direct SQL queries.
  • Use: GlideRecord is fundamental for server-side scripting in ServiceNow. It's used in Business Rules, Script Includes, Workflows, and other server-side scripts to:
    • Retrieve data from tables.
    • Create new records.
    • Update existing records.
    • Delete records.
    • Query records based on conditions.
    • Iterate through record sets.

Question 17: Tell me some Glide APIs which are running from server-side.

Answer: Some Glide APIs that primarily run on the server-side in ServiceNow include:

  • GlideRecord: For database interaction (CRUD operations).
  • GlideSystem (gs): Provides access to system-level information and functions (logging, events, user session, etc.).
  • GlideDateTime: For working with dates and times.
  • GlideDate: For working with dates only.
  • GlideTime: For working with times only.
  • GlideSession: For managing user sessions.
  • GlideMutex: For creating mutex locks to synchronize server-side scripts and prevent race conditions.
  • GlideAggregate: For performing aggregate queries (sum, count, average, min, max).

Question 18: What is the difference between Glide Record and Glide Aggregate?

Answer:

  • Glide Record: Primarily used for standard CRUD operations on ServiceNow tables: fetching individual records, creating, updating, and deleting records. It retrieves records row by row.

  • Glide Aggregate: Used for performing aggregate calculations on a set of records. It allows you to calculate:

    • sum(): Sum of values in a field.
    • count(): Number of records matching criteria.
    • average(): Average value of a field.
    • min(): Minimum value of a field.
    • max(): Maximum value of a field.
    • groupBy(): Group results based on a field value.

  • Key Difference: GlideRecord is for record-level operations, while GlideAggregate is for performing calculations across groups of records. GlideAggregate is generally more efficient for aggregate calculations than iterating through GlideRecord results and manually calculating aggregates. While GlideAggregate can be used to fetch records (similar to query() in GlideRecord), its primary purpose is aggregation.

Question 19: Tell me client-side APIs.

Answer: Some common client-side APIs in ServiceNow include:

  • GlideForm (g_form): For interacting with the current form (getting and setting field values, making fields mandatory/read-only/visible, adding UI messages, etc.).
  • GlideUser (g_user): For accessing information about the currently logged-in user (username, roles, groups, etc.).
  • GlideMenu (g_menu): For manipulating form context menus (adding, removing menu items).
  • GlideAjax: For making asynchronous calls to server-side Script Includes from client-side scripts (to execute server-side logic and retrieve data without page reload).

Question 20: Tell me some methods in Glide Record.

Answer: Some common and important methods in GlideRecord include:

  • addQuery(): Adds a condition to the query.
  • addEncodedQuery(): Adds a query condition using an encoded query string (often copied from a list filter).
  • query(): Executes the query against the database.
  • next(): Moves to the next record in the result set (used in a while loop).
  • hasNext(): Checks if there is another record in the result set.
  • get(): Retrieves a single record based on a sys_id or other unique identifier.
  • insert(): Inserts a new record.
  • update(): Updates the current record.
  • deleteRecord(): Deletes the current record.
  • deleteMultiple(): Deletes multiple records matching a query.
  • setValue(): Sets the value of a field in the current record.
  • getValue(): Gets the value of a field in the current record.
  • setDisplayValue(): Sets the display value of a field (for reference fields).
  • getDisplayValue(): Gets the display value of a field.
  • orderBy(): Orders the result set in ascending order by a field.
  • orderByDesc(): Orders the result set in descending order by a field.
  • setLimit(): Limits the number of records returned by the query.
  • setWorkflow(boolean): Controls whether business rules and workflows are triggered during insert/update operations (default is true).
  • setForceUpdate(): Forces an update even if no field values have changed.
  • getRowCount(): Returns the total number of records that match the query without retrieving the actual records (more efficient for counting).
  • isValidRecord(): Checks if the current GlideRecord object points to a valid record.

Question 21: Tell me some methods in Glide Form.

Answer: Some common methods in GlideForm (g_form) include:

  • setValue(fieldName, value): Sets the value of a form field.
  • getValue(fieldName): Gets the value of a form field.
  • setDisplayValue(fieldName, displayValue): Sets the display value of a field (especially for reference fields).
  • getDisplayValue(fieldName): Gets the display value of a field.
  • setMandatory(fieldName, mandatory): Makes a field mandatory (true) or optional (false).
  • setReadOnly(fieldName, readOnly): Makes a field read-only (true) or editable (false).
  • setVisible(fieldName, visible): Makes a field visible (true) or hidden (false).
  • setDisabled(fieldName, disabled): Disables a field (true) or enables it (false).
  • clearValue(fieldName): Clears the value of a field.
  • addInfoMessage(message): Displays an information message at the top of the form.
  • addErrorMessage(message): Displays an error message at the top of the form.
  • addDecoration(fieldName, icon, title): Adds an icon decoration to a field.
  • flash(fieldName, color, count): Briefly flashes the background color of a field.

Question 22: Scenario-based question: "I want to print all the active tickets where category is network which are created today." (and code to do this)

Answer: (Code provided in the transcript is a good example, explained below)

Code Example (from transcript, with explanation):

var inc = new GlideRecord('incident'); // Initialize GlideRecord for the 'incident' table

inc.addActiveQuery(); // Add condition to get only active incidents (state is active)
inc.addQuery('category', 'network'); // Add condition to filter by category 'network'
// Removed condition to filter by created today as per transcript discussion

inc.setLimit(5); // Limit the result to 5 tickets
inc.query(); // Execute the query

while (inc.next()) { // Loop through each record in the result set
  gs.print(inc.number); // Print the 'number' field of each incident record
}

Explanation:

  1. var inc = new GlideRecord('incident');: Creates a GlideRecord object named inc for the 'incident' table.
  2. inc.addActiveQuery();: Adds a condition to the query to only retrieve records where the 'active' field is true (meaning active incidents). This is a shortcut for inc.addQuery('active', 'true');.
  3. inc.addQuery('category', 'network');: Adds a condition to filter incidents where the 'category' field is 'network'.
  4. inc.setLimit(5);: Limits the maximum number of records returned by the query to 5.
  5. inc.query();: Executes the query against the database.
  6. while (inc.next()) { ... }: Starts a loop that iterates through each record that matches the query results. inc.next() moves to the next record and returns true if there is a record, false otherwise.
  7. gs.print(inc.number);: Inside the loop, gs.print() writes to the ServiceNow system log (and the background scripts output). inc.number retrieves the 'number' field value of the current incident record.

Note: The condition to filter by "created today" was removed in the transcript discussion because the user likely didn't have incidents meeting all three criteria (active, network category, created today). To add a "created today" condition, you would need to use GlideDateTime or GlideDate APIs to construct the correct date range query.

Question 23: What is Glide Ajax and importance of it?

Answer:

  • Glide Ajax: A ServiceNow API that allows you to make asynchronous calls from client-side scripts (Client Scripts, UI Actions) to server-side Script Includes. It enables client-side scripts to execute server-side logic and retrieve data without requiring a full page reload.
  • Importance:
    • Improved User Experience: Provides a more responsive user interface by performing server-side operations in the background without blocking the user's interaction with the form.
    • Client-Side Logic with Server-Side Data: Allows you to implement complex client-side logic that relies on server-side data or processing.
    • Reduced Server Load (sometimes): By moving some processing to the client-side and making efficient AJAX calls, you can potentially reduce the load on the ServiceNow server compared to full page reloads for every interaction.
    • Real-time Validation and Updates: Enables real-time form validation against server-side data or updating form fields based on server-side calculations without page refreshes.

Question 24: How many ways we do get the data from server to client?

Answer: There are three primary ways to get data from the server-side to the client-side in ServiceNow:

  1. Display Business Rule with g_scratchpad: As explained in Question 7, Display Business Rules use the g_scratchpad object to pass server-side data to client-side scripts. This is suitable for data that is needed when the form initially loads.
  2. GlideRecord (using getReference() method in Client Script): The getReference() method in GlideForm (client-side) can be used to asynchronously fetch data from a server-side GlideRecord query. However, it's generally less preferred for complex data retrieval or logic compared to GlideAjax.
  3. Glide Ajax: The most robust and flexible method for retrieving data from the server to the client. GlideAjax allows you to call server-side Script Includes and pass parameters, execute server-side logic, and receive data back to the client. It is generally considered the best practice for most client-server data interactions due to its efficiency and flexibility.

Question 25: How many types of Glide Ajax?

Answer: There are two main ways to make GlideAjax calls:

  1. Asynchronous GlideAjax (using getXML()): This is the most common type. The client-side script sends a request to the server, and the script continues execution without waiting for the server's response. When the server responds, a callback function is executed to handle the response. This is non-blocking and improves user experience. Uses the getXML() method.

  2. Synchronous GlideAjax (using getXMLWait()): The client-side script sends a request to the server and waits for the server to respond before continuing execution. This is blocking, meaning the browser might appear unresponsive while waiting. Synchronous GlideAjax should be used sparingly, as it can negatively impact user experience. Uses the getXMLWait() method.

Question 26: Write the syntax of Glide Ajax.

Answer: (Standard GlideAjax syntax example provided in the transcript and explained below)

Standard Asynchronous GlideAjax Syntax (from transcript):

var ga = new GlideAjax('ScriptName'); // 'ScriptName' is the name of your Script Include
ga.addParam('sysparm_name', 'methodName'); // 'methodName' is the name of the function in your Script Include to call
ga.addParam('sysparm_fieldName', 'fieldValue'); // Example of passing a parameter to the Script Include
ga.getXML(processResponse); // Asynchronous call, 'processResponse' is the callback function

function processResponse(response) {
  var answer = response.responseXML.documentElement.getAttribute("answer"); // Extract 'answer' attribute from the XML response
  alert(answer); // Example: Display the answer in an alert
}

Explanation:

  1. var ga = new GlideAjax('ScriptName');: Creates a new GlideAjax object. 'ScriptName' is a string representing the name of the Script Include you want to call on the server-side.
  2. ga.addParam('sysparm_name', 'methodName');: Adds a parameter named 'sysparm_name' with the value 'methodName'. 'methodName' must be the name of a function defined within your Script Include that you want to execute. This is how you specify which server-side function to call.
  3. ga.addParam('sysparm_fieldName', 'fieldValue');: Adds additional parameters to be passed to the Script Include function. Parameters should be prefixed with sysparm_. 'sysparm_fieldName' is the parameter name, and 'fieldValue' is the value you want to send. You can add multiple parameters using addParam().
  4. ga.getXML(processResponse);: Makes the asynchronous call to the server. 'processResponse' is the name of a JavaScript function that will be executed when the server responds. This is the callback function.
  5. function processResponse(response) { ... }: The callback function. It receives the server's response as a response object.
    • response.responseXML.documentElement.getAttribute("answer");: This line extracts the value of the answer attribute from the XML response sent back by the Script Include. Important: In your Script Include, you need to use ajaxResponse.getXMLAnswer(answerValue); to send data back to the client, where answerValue is the data and it will be accessible on the client-side as the "answer" attribute in the XML response.
    • alert(answer);: Example of how to use the retrieved data (in this case, displaying it in an alert).

Question 27: What is Script Include?

Answer:

  • Script Include: A reusable server-side JavaScript code module in ServiceNow. It's like a library or class that contains functions and classes that can be called from other server-side scripts (Business Rules, Workflows, other Script Includes) and, with GlideAjax, from client-side scripts.
  • Purpose:
    • Code Reusability: Avoids code duplication by writing functions or classes once in a Script Include and reusing them in multiple scripts across the platform.
    • Modularity and Organization: Helps organize server-side code into logical modules, making code easier to maintain and understand.
    • Improved Performance (potentially): By centralizing common logic in Script Includes, you can improve code maintainability and potentially performance compared to embedding the same logic in many different scripts.

Question 28: How many types of Scripting Clouds are there in ServiceNow? (This is likely a typo in the transcript, and the question intended is "How many types of Script Includes are there?")

Answer (Assuming "Script Includes" is intended): There are a few ways to categorize Script Includes, but commonly they are described by their client-callable status and class structure:

  1. Client-Callable Script Includes: These are Script Includes that are designed to be called from client-side scripts using GlideAjax. To make a Script Include client-callable, you need to:

    • Set the "Client callable" checkbox to true in the Script Include record.
    • The Script Include's class should typically extend AbstractAjaxProcessor. ServiceNow automatically handles the communication between GlideAjax and Script Includes extending this class.

  2. Server-Side Script Includes (Not Client-Callable): These Script Includes are meant to be used only on the server-side (from Business Rules, Workflows, other Script Includes). They are not intended to be directly called from the client-side via GlideAjax. They are typically used for encapsulating server-side logic for reusability within server-side scripts. They can be classless (just a collection of functions) or define classes.

  3. Classless Script Includes (On-Demand): These Script Includes do not define a class structure. They are simply a collection of functions. They are often used for utility functions or small sets of related functions. They are loaded into memory only when they are first called (hence "on-demand").

  4. Class-Based Script Includes (with Classes): These Script Includes define classes using JavaScript's class syntax (or older prototype-based syntax). This allows for object-oriented programming principles in ServiceNow server-side scripting. They can be used for more complex logic and data structures.

Question 29: Can we call Script Include into Client Side?

Answer: Yes, you can call a Script Include from the client-side using GlideAjax. To do this, the Script Include must be configured to be client-callable (as explained in Question 28). When you create a Script Include and check the "Client callable" checkbox, ServiceNow typically automatically sets the "Extensible by" field to AbstractAjaxProcessor (or allows you to select it). This makes the Script Include accessible via GlideAjax calls from client-side scripts.

Question 30: How do you configure notification body in any notification?

Answer: To configure the notification body in ServiceNow, you can use a combination of HTML, plain text, and dynamic content (variables and scriptlets). For more complex and reusable notification content, you can use Email Scripts (Mail Scripts).

Using Email Scripts in Notification Body:

  1. Create an Email Script: Navigate to System Policy > Email > Notification Email Scripts. Create a new Email Script.

    • Name: Give it a unique name (e.g., incident_resolution_details).
    • API Name: ServiceNow automatically generates this based on the name. This is what you'll use to reference the script in the notification.
    • Script: Write your JavaScript code to generate the desired content for the notification body. You can use GlideRecord to fetch data, format information, etc. The script should typically output HTML or plain text content.

  2. Call Email Script in Notification Body: In your Notification record, in the "Message HTML" or "Message plain text" section, use the following syntax to call your Email Script:

    ${mail_script:email_script_api_name}

    Replace email_script_api_name with the API Name of the Email Script you created (e.g., incident_resolution_details).

    Example:

    If your Email Script API Name is incident_resolution_details, in your notification body, you would write:

    <p>Incident ${number} has been resolved.</p>
<p>Resolution Details:</p>
${mail_script:incident_resolution_details}
<p>Thank you,</p>
<p>Service Desk</p>

    ServiceNow will execute the incident_resolution_details Email Script and insert its output into the notification body at that point.

Question 31: What are SLAs and types of SLAs?

Answer:

  • SLA (Service Level Agreement): A formal agreement between a service provider and a customer (or business unit) that defines the level of service expected. It typically outlines metrics like response time, resolution time, and uptime.
  • Types of SLAs in ServiceNow:
    1. SLA (Service Level Agreement): The standard SLA, as described above, between a business unit (customer) and a service provider (IT department, etc.). It defines service commitments to external or internal customers.
    2. OLA (Operational Level Agreement): An agreement within an organization, between different internal teams or departments that support the delivery of a service. OLAs define responsibilities and timelines for internal teams to ensure SLAs are met. Example: An OLA between the Network team and the Server team to ensure server availability for an application covered by an SLA.
    3. UC (Underpinning Contract): An agreement between a service provider and a third-party vendor that supports the service provider in delivering services to the customer. UCs define the terms of service from external vendors that are necessary to meet SLAs. Example: A UC with a cloud provider for infrastructure services that support an application covered by an SLA.

Question 32: What is Retract to Start and Retract to End pass? (Likely "Retract Start and Reset on Pause")

Answer (Assuming "Retract Start and Reset on Pause" is intended, based on common SLA concepts):

These settings are related to how ServiceNow calculates SLA timelines, particularly when SLAs are paused or when conditions change.

  • Retract Start: This setting (usually a checkbox in SLA Definition records) affects what happens to the SLA start time when the SLA's start conditions are no longer met.

    • If "Retract Start" is enabled (checked): If the conditions that initially started the SLA cease to be true, the SLA will be canceled or retracted. The SLA timer stops, and the SLA is essentially abandoned. This is useful when an SLA should only be active as long as specific conditions are true.
    • If "Retract Start" is disabled (unchecked): The SLA, once started, will continue to run even if the initial start conditions become false.

  • Reset on Pause (or "Pause condition resets start time"): This setting (also usually a checkbox) determines if pausing an SLA should reset its start time when it is resumed.

    • If "Reset on Pause" is enabled (checked): When an SLA is paused (due to a pause condition being met), and then later resumed (pause condition no longer met), the SLA's start time is reset to the time of resumption. This effectively restarts the SLA timer from the point of resumption.
    • If "Reset on Pause" is disabled (unchecked): When an SLA is paused and resumed, the SLA timer continues from where it left off when paused. The start time is not reset.

Example Scenario:

Imagine an SLA for Incident resolution with a target of 1 hour for Priority 1 incidents.

  • Retract Start Example: If you have "Retract Start" enabled and the Incident priority is changed from Priority 1 to Priority 3 after the SLA has started, the SLA might be retracted (canceled) because the Priority 1 condition is no longer met.

  • Reset on Pause Example: If you have "Reset on Pause" enabled and the SLA is paused when the Incident is put "On Hold" waiting for customer input. When the Incident is taken "Off Hold", the SLA timer could either:

    • With "Reset on Pause" (checked): Reset and start counting the 1-hour SLA target from the time it's taken "Off Hold".
    • Without "Reset on Pause" (unchecked): Continue counting down from where it was when paused (e.g., if it had 45 minutes remaining when paused, it will still have 45 minutes remaining when resumed).

Question 33: What is ACL and types of ACLs?

Answer:

  • ACL (Access Control List): A security mechanism in ServiceNow that controls access to objects and operations within the platform. ACLs define who can perform what actions (create, read, update, delete) on specific ServiceNow resources (tables, fields, records).
  • Types of ACLs (Operation Types): ACLs are defined by the operation they control. The main operation types are:
    1. Create: Controls who can create new records in a table.
    2. Read: Controls who can view records in a table (or specific fields).
    3. Write: Controls who can update existing records in a table (or specific fields).
    4. Delete: Controls who can delete records from a table.

Question 34: How many levels we can apply ACL rules?

Answer: ACL rules in ServiceNow can be applied at two levels:

  1. Table-Level ACL: An ACL rule that applies to the entire table. It controls access to all records in the table (for a given operation like read, write, create, delete) unless a more specific field-level ACL overrides it. Table-level ACLs are defined with the "Field" field left blank in the ACL record.

  2. Field-Level ACL: An ACL rule that applies to a specific field on a table. Field-level ACLs are defined with a specific field name in the "Field" field of the ACL record. Field-level ACLs are more granular and can override table-level ACLs for that particular field.

Hierarchy/Precedence: Field-level ACLs take precedence over table-level ACLs. If a user has access at the table level but is denied access by a field-level ACL, the field-level ACL will prevail, and the user will not be able to access that specific field (even if they can access other fields in the record).

Question 35: What about star and none? (In the context of ACLs, likely referring to table/field naming conventions in ACL rules)

Answer: In the context of ServiceNow ACLs, "star" (*) and "none" are special naming conventions used for defining ACL rules:

  • * (Star or Wildcard):

    • Table Name: * as the table name in an ACL rule means the rule applies to all tables in the ServiceNow instance. This is very powerful and should be used with extreme caution as it can affect security across the entire platform.
    • Field Name: * as the field name in an ACL rule means the rule applies to all fields on the specified table (or all tables if the table name is also *). Again, use with caution.

  • none:

    • Table Name: none as the table name in an ACL rule is used to create a default table-level ACL rule. It acts as a baseline rule for all tables that do not have more specific table-level ACLs defined. It's often used to set a default access policy.

Examples:

  • table: * , operation: read: An ACL rule with table name * and operation read would apply to all tables for read access. You would then likely need more specific ACLs to restrict access to certain tables or fields.
  • table: incident , field: * , operation: write: An ACL rule for the 'incident' table with field name * and operation write would apply to all fields on the 'incident' table for write access.
  • table: none , operation: read: A none table ACL for read would define a default read access rule for all tables that don't have more specific read ACLs defined. You might set this to require a specific role for read access by default and then create more permissive ACLs for certain tables.

Question 36: Which is best practice to add the roles: user or group?

Answer: Group is generally the best practice for assigning roles in ServiceNow.

Reasons why groups are preferred:

  • Scalability and Maintainability: Managing roles at the group level is much more scalable and easier to maintain than assigning roles directly to individual users. If you have many users who need the same roles, adding them to a group and assigning roles to the group is far more efficient than assigning roles to each user individually.
  • Simplified User Management: When users join or leave teams or departments, you only need to update their group membership, not their individual roles. This simplifies user administration significantly.
  • Role Inheritance: Roles assigned to a group are automatically inherited by all members of that group. This ensures consistent role assignments and reduces the risk of accidentally missing roles for users.
  • Auditing and Reporting: Group-based role assignments make it easier to audit and report on who has access to what. You can quickly see which roles are assigned to a group and, therefore, which users within that group have those roles.

When User-Level Role Assignment Might Be Used (Less Common):

  • Exceptions or Specific Needs: In rare cases, you might need to assign a role directly to a user if they need access that is different from their team or group. However, this should be an exception rather than the rule.
  • Very Small Organizations: In very small organizations with few users and minimal team structure, user-level role assignment might seem simpler initially, but it will quickly become harder to manage as the organization grows.

In summary, always strive to use groups for role assignment in ServiceNow for better manageability, scalability, and maintainability.

Question 37: What is the difference between UI Policy and Client Scripts?

Answer: (Detailed comparison of UI Policy and Client Scripts as already provided in Question 1 and Question 2, and further elaborated below)

Key Differences Summarized:

Feature UI Policy Client Script
Execution Client-side Client-side
Configuration Declarative (mostly configuration-driven) Scripting (requires JavaScript coding)
Purpose Basic UI behavior changes (form-level) Complex UI behavior, data manipulation, events
Use Cases Simple form field manipulation (mandatory, read-only, visible), based on conditions Complex form logic, validation, interactions, data processing, event handling
Performance Generally more performant for simple tasks Can be less performant if poorly written or complex
Learning Curve Easier to learn and configure Requires JavaScript knowledge
Debugging Easier to debug Can be more complex to debug
Features Limited to predefined actions (mandatory, read-only, visible) More flexible, can perform a wider range of actions
Trigger Events Form load, field value change onLoad, onSubmit, onChange, onCellEdit

In essence:

  • UI Policies are for simpler, declarative UI changes that can be achieved through configuration, primarily focused on making fields mandatory, read-only, or visible based on conditions. They are easier to use for basic form behavior modifications.
  • Client Scripts are for more complex, script-driven UI behavior, validation, and interactions. They offer greater flexibility but require JavaScript coding skills and can be more complex to implement and debug.

Question 38: Scenario-based question: "I made short description field mandatory via client scripts and same field unmandatory via UI policy, so what would be the final result?"

Answer: The final result would be that the Short description field will be unmandatory.

Explanation:

  • Execution Order: Client Scripts generally execute before UI Policies in the ServiceNow client-side engine. However, when there is a conflict or overlap in their actions, UI Policies take precedence over Client Scripts for the same form element.
  • UI Policy Overrides Client Script: Even though the Client Script initially makes the field mandatory, the UI Policy, which is processed later in the form rendering pipeline, sets it to unmandatory. Therefore, the UI Policy's action overrides the Client Script's action.
  • Final Output: When the form is rendered, the UI Policy's setting (unmandatory) will be the final state of the Short description field.

Question 39: Scenario-based question: "I have written two UI policies and two client scripts, so which are exporting first?" (Likely intended to be "executing first")

Answer (Assuming "executing first" is intended):

In general, Client Scripts execute before UI Policies in the ServiceNow client-side processing order.

Execution Order (Approximate):

  1. Client Scripts:

    • onLoad Client Scripts
    • onChange Client Scripts (if triggered by initial form load or field value changes)
    • onSubmit Client Scripts (when form is submitted)
    • onCellEdit Client Scripts (when list cells are edited)

  2. UI Policies: UI Policies are evaluated and applied after Client Scripts have executed during form load and field value changes.

Within each category (Client Scripts or UI Policies):

  • The order of execution for multiple Client Scripts or UI Policies of the same type (e.g., two onLoad Client Scripts, two UI Policies triggering on the same condition) is not guaranteed to be in a specific order. ServiceNow doesn't explicitly define a strict execution order for multiple scripts/policies of the same type triggered by the same event.

Therefore, in your scenario:

  • The two Client Scripts would generally execute before the two UI Policies.
  • However, the exact order within the two Client Scripts or within the two UI Policies is not guaranteed.

Important Note: It's generally bad practice to rely on the execution order of multiple Client Scripts or UI Policies that are trying to modify the same form elements in overlapping ways. This can lead to unpredictable behavior and make your code harder to maintain. It's better to design your Client Scripts and UI Policies to be as independent and non-conflicting as possible, or to carefully coordinate their actions if they need to interact.

Question 40: What is Service Catalog and use of it?

Answer:

  • Service Catalog: An application within ServiceNow that provides a user-friendly, self-service portal for users to request services, products, and information from IT and other departments within an organization. It's essentially an online catalog of services offered by the organization.
  • Use and Purpose:
    • Self-Service: Empowers users to request services themselves, reducing the need to contact help desks or IT support directly for routine requests.
    • Standardization and Automation: Service Catalog helps standardize service requests and automate fulfillment processes through workflows and automation.
    • Improved User Experience: Provides a consistent and user-friendly interface for requesting services compared to manual or ad-hoc methods.
    • Service Portfolio Management: Helps organizations manage and promote their service offerings in a structured way.
    • Reduced Costs: Automation and self-service can lead to cost savings by reducing manual effort and improving efficiency.
    • Centralized Request Management: Provides a central place for users to submit, track, and manage their service requests.

Question 41: What is Record Producer?

Answer:

  • Record Producer: A type of catalog item in ServiceNow Service Catalog. It provides an alternative way to create task-based records (like Incident, Change Request, Problem, etc.) directly from the Service Catalog interface.
  • Purpose:
    • Simplified Record Creation: Offers a simplified and user-friendly form for creating records compared to navigating directly to the table and filling out a standard form.
    • Guided Data Entry: Record Producers can be designed with specific questions and fields relevant to the type of record being created, guiding users to provide the necessary information.
    • Customizable Forms: You can customize the Record Producer form to present a specific set of fields or questions, hiding fields that are not relevant or needed for initial record creation.
    • Alternative to Regular Forms: Provides an alternative to using the standard table forms for record creation, especially for common or frequently requested record types.
    • Example: A Record Producer for "Report an Issue" in the Service Catalog might present a simplified form with fields like "Issue Description," "Category," and "Impact," making it easier for users to report incidents compared to using the full Incident form.

Question 42: What is Order Guide?

Answer:

  • Order Guide: A type of catalog item in ServiceNow Service Catalog that allows users to request multiple related catalog items in a single request. It helps bundle services or products that are often requested together.
  • Purpose:
    • Bundling Services: Simplifies the request process for complex services that involve multiple individual items or steps.
    • Guided Ordering: Guides users through the process of ordering related items, ensuring they select all necessary components.
    • Reduced Request Overhead: Users can submit one order instead of multiple individual requests, streamlining the fulfillment process.
    • Example: An Order Guide for "New Employee Onboarding" might include catalog items for requesting a laptop, user account creation, building access, and phone setup, all bundled into a single request.

Question 43: What is Cascade Variable in Order Guide?

Answer:

  • Cascade Variable: A property (checkbox) in ServiceNow Order Guides. When enabled, it allows variable values entered on the initial Order Guide form to be automatically copied (cascaded) down to the individual catalog items and record producers included in the Order Guide.
  • Purpose:
    • Data Propagation: Reduces redundant data entry for users when requesting multiple related items. If several items in an Order Guide require the same information (e.g., user's name, department, location), users only need to enter it once on the Order Guide form, and it's automatically populated in the individual item forms.
    • Improved User Experience: Streamlines the ordering process and makes it faster and easier for users to request bundled services.
    • Data Consistency: Ensures that consistent information is used across all items within an Order Guide request.

How it works:

When "Cascade Variable" is enabled in an Order Guide:

  1. Variables on Order Guide Form: You define variables on the Order Guide's main form.
  2. Matching Variables in Catalog Items/Record Producers: If catalog items or record producers included in the Order Guide have variables with the same names as the variables on the Order Guide form, the values entered on the Order Guide form will be automatically copied to those matching variables in the individual items when the Order Guide is submitted.

Question 44: What is User Criteria?

Answer:

  • User Criteria: A feature in ServiceNow that allows you to define rules to control who can access or interact with specific ServiceNow features, primarily in the Service Catalog (e.g., catalog items, record producers, order guides) and Knowledge Base.
  • Purpose:
    • Targeted Access Control: Enables you to precisely control which users or groups can:
      • See and request specific catalog items or order guides (Availability User Criteria).
      • Contribute to or view specific knowledge bases or knowledge articles (Knowledge Base User Criteria).
    • Personalization: Allows you to tailor the Service Catalog and Knowledge Base experience based on user roles, groups, departments, locations, or other criteria.
    • Security and Compliance: Helps enforce access control policies and ensure that users only see and request services or information relevant to their roles and responsibilities.

How User Criteria Works:

You define User Criteria records that specify conditions based on:

  • Roles: Users must have specific roles.
  • Groups: Users must be members of specific groups.
  • Departments: Users must belong to specific departments.
  • Locations: Users must be in specific locations.
  • Scripts: You can use JavaScript scripts to define more complex conditions based on user properties or other criteria.

You then associate User Criteria with Service Catalog items, Knowledge Bases, or Knowledge Articles to control who can access them.

Types of User Criteria (in Service Catalog):

  • Available For: User Criteria associated with "Available For" control who can see and request a catalog item or order guide.
  • Not Available For: User Criteria associated with "Not Available For" control who cannot see and request a catalog item or order guide. "Not Available For" criteria take precedence over "Available For" criteria.

Question 45: What is Variable Set?

Answer:

  • Variable Set: A reusable group or collection of variables in ServiceNow. Variable Sets are used primarily in Service Catalog items (Catalog Items, Record Producers, Order Guides) and Content Items.
  • Purpose:
    • Reusability: Avoids recreating the same set of variables across multiple catalog items or content items. If you have a group of variables that are commonly used together (e.g., user information variables like "User Name," "Department," "Location"), you can define them once in a Variable Set and then reuse that set in multiple catalog items or content items.
    • Organization and Maintainability: Makes catalog item and content item definitions more organized and easier to maintain by grouping related variables together.
    • Consistency: Ensures consistency in variable definitions and usage across different catalog items or content items.
    • Reduced Development Time: Saves time for developers and administrators by reducing the need to define the same variables repeatedly.

Types of Variable Sets:

  • Single Row Variable Sets: These are the most common type. They present a single set of variables to the user, typically displayed in a single section on the catalog item form.
  • Multi Row Variable Sets (MRVS): Allow users to enter multiple rows of data for a set of variables. Think of it like a mini-table embedded within the catalog item form. Users can dynamically add and remove rows to input multiple instances of the variable set (e.g., multiple software requests, multiple hardware items).

Question 46: What is Update Set?

Answer:

  • Update Set: A mechanism in ServiceNow for capturing and grouping configuration changes and customizations made in a ServiceNow instance. Update Sets are used to migrate these changes from one ServiceNow instance (e.g., development or testing instance) to another (e.g., production instance).
  • Purpose:
    • Change Management: Provides a controlled and auditable way to move changes between ServiceNow environments.
    • Deployment and Migration: Simplifies the process of deploying customizations and configurations to different instances.
    • Version Control (Basic): Offers a basic form of version control for ServiceNow configurations.
    • Rollback (Limited): In some cases, Update Sets can be used to rollback changes, although it's not their primary purpose and rollback can be complex.

Procedure/Workflow for using Update Sets (as described in the transcript):

  1. Create a Local Update Set: In your development instance, before making any configuration changes, create a new Local Update Set (System Update Sets > Local Update Sets > New). Give it a descriptive name. Set it as the "Current" update set (ServiceNow may prompt you to do this automatically when you create one).
  2. Make Configuration Changes: Perform your ServiceNow configuration changes (create Business Rules, Client Scripts, UI Policies, workflows, etc.) while your Update Set is set as "Current". ServiceNow automatically tracks and records these changes within the "Current" Update Set.
  3. Complete the Update Set: Once you've finished making all the changes for a specific release or project, navigate to your Local Update Set and click the "Complete Update Set" button. This marks the Update Set as complete and prevents further changes from being added to it. ServiceNow will generate an XML file representing the changes in the Update Set.
  4. Export the Update Set (XML File): After completing the Update Set, you can download or export the generated XML file. This file contains all the captured configuration changes.
  5. Import the Update Set into Target Instance: In your target ServiceNow instance (e.g., production), navigate to System Update Sets > Retrieved Update Sets > Import Update Set from XML. Upload the XML file you exported from the source instance.
  6. Preview Update Set: After importing, open the Retrieved Update Set record. Click the "Preview Update Set" button. This simulates applying the changes in the target instance and identifies potential conflicts or errors (like collisions). Review the preview results carefully.
  7. Commit Update Set: If the preview is successful and you're satisfied with the changes, click the "Commit Update Set" button. This applies the configuration changes from the Update Set to the target instance.

Question 47: What is Import Sets?

Answer:

  • Import Sets: An application in ServiceNow designed for importing bulk data into ServiceNow tables from external data sources. Import Sets provide a staged and controlled process for data import, including data transformation and error handling.
  • Purpose:
    • Bulk Data Loading: Efficiently import large volumes of data from external systems or files into ServiceNow.
    • Data Integration: Facilitates data integration between ServiceNow and other systems.
    • Data Migration: Used for migrating data from legacy systems into ServiceNow.
    • Data Loading for Testing and Development: Populate ServiceNow instances with test data or development data.

Procedure/Workflow for using Import Sets (as described in the transcript):

  1. Load Data into Staging Table (Import Set Table):

    • Choose Data Source: Select the external data source (file like XML, Excel, CSV, JSON; or JDBC, etc.).
    • Create Import Set Table: ServiceNow can automatically create a staging table (called an "Import Set Table") to temporarily hold the data from your source file. This table typically mirrors the structure of your source data.
    • Load Data: Use the "Load Data" functionality in ServiceNow to import data from your source file into the Import Set Table.

  2. Create Transform Map:

    • Define Target Table: Specify the ServiceNow table where you want to ultimately import the data (e.g., Incident, User, etc.).
    • Map Source Fields to Target Fields: Create a Transform Map. This map defines how fields in your Import Set Table should be mapped to fields in your Target Table. You specify which source field corresponds to which target field.
    • Field Mapping: Define mapping rules for each field, including:
      • Source Field: The field in the Import Set Table.
      • Target Field: The field in the Target Table.
      • Transform Scripts (Optional): Use scripts to perform data transformations, data cleansing, or lookups during the import process.

  3. Run Transform (Transform Map):

    • Execute Transform: Run the Transform Map. ServiceNow reads the data from the Import Set Table, applies the field mappings and transform scripts defined in your Transform Map, and inserts or updates records in your Target Table.

  4. Coalesce Fields (Optional but Important for Updates and Deduplication):

    • Coalesce Field Property: In your Transform Map, for one or more fields, set the "Coalesce" property to true.
    • Purpose of Coalesce: Coalesce fields are used to determine if an incoming record from the Import Set should insert a new record into the Target Table or update an existing record in the Target Table.
      • If a record with matching coalesce field values exists in the Target Table: The Transform Map will update the existing record with the data from the Import Set.
      • If no record with matching coalesce field values exists: The Transform Map will insert a new record into the Target Table.
    • Example: If you are importing user data and want to update existing users based on their "User ID" (a unique identifier), you would set "User ID" as the coalesce field in your Transform Map.

Question 48: What is Metric and use of it?

Answer:

  • Metric (ServiceNow Metrics): A feature in ServiceNow that allows you to track and measure the lifecycle and effectiveness of processes within ServiceNow. Metrics capture data points at different stages of a record's lifecycle, enabling you to analyze process efficiency, identify bottlenecks, and track key performance indicators (KPIs).
  • Purpose:
    • Process Measurement and Analysis: Quantify and analyze the performance of ServiceNow processes (e.g., Incident Management, Change Management, Request Fulfillment).
    • Identify Bottlenecks: Pinpoint stages in a process where delays or inefficiencies occur.
    • Track SLAs and KPIs: Measure adherence to Service Level Agreements and track key performance indicators related to service delivery.
    • Reporting and Dashboards: Provide data for reports and dashboards to visualize process performance and trends.
    • Continuous Improvement: Data from metrics can be used to drive process improvements and optimize service delivery.

How Metrics Work:

  1. Metric Definition: You create Metric Definition records. These define:

    • Table: The ServiceNow table you want to track metrics on (e.g., Incident, Change Request).
    • Field: The field on the table whose changes you want to track (e.g., State, Assignment Group).
    • Type: The type of metric (e.g., Field value duration, Script calculation).
    • Script (Optional): For more complex metrics, you can use a script to define how the metric is calculated.

  2. Metric Instance Creation: When a record is created or updated on the table specified in the Metric Definition, ServiceNow automatically creates a Metric Instance record.

    • Metric Instance records store:
      • The record being tracked (e.g., the Incident record).
      • The Metric Definition it's based on.
      • The value of the tracked field at the time of the metric event.
      • Timestamps (start and end times of metric stages).
      • Duration of stages.

  3. Data Analysis and Reporting: You can then use the Metric Instance data to generate reports, dashboards, and analyze process performance. Common metrics tracked include:

    • Time spent in different states.
    • Time taken for assignment.
    • Resolution times.
    • Average handle times.

Question 49: Can we delete any predefined table?

Answer: No, you cannot delete any predefined or out-of-the-box (OOTB) tables in ServiceNow. ServiceNow's core tables (like Incident, Problem, Change Request, User, Task, etc.) are fundamental to the platform's functionality and are protected from deletion.

Why you can't delete predefined tables:

  • System Stability: Predefined tables are essential for the core operations of ServiceNow. Deleting them would break critical functionality and system stability.
  • Data Integrity: Deleting tables could lead to data loss and corruption, as many other tables and processes depend on these core tables.
  • Upgrade Compatibility: ServiceNow upgrades rely on the structure and presence of predefined tables. Deleting them could cause upgrade failures or instability.

What you can do:

  • Customize: You can heavily customize predefined tables:
    • Add new fields.
    • Modify existing fields (within limits).
    • Add Business Rules, Client Scripts, UI Policies, etc.
    • Create relationships to other tables.
  • Archive Data: If you need to manage the size of your tables, you can use ServiceNow's archiving features to move older data to archive tables, but you cannot delete the base tables themselves.
  • Hide Tables from UI (Limited): You can control which tables are visible in the ServiceNow UI to certain users or roles, but this does not delete the table.

Question 50: How we come to know which version of ServiceNow you are using in your project?

Answer: There are several ways to determine the ServiceNow version of an instance you are using:

  1. System Information Page:

    • In ServiceNow, navigate to System Diagnostics > System Information.
    • On the System Information page, look for the "Instance Name" field. The instance name usually includes the ServiceNow release name (e.g., "instance.service-now.com - Quebec").
    • Also, on this page, you'll find more detailed version information under "Build name" and "Build date".

  2. Login Page URL (Often):

    • Examine the URL of your ServiceNow login page. Sometimes the release name is included in the URL itself (e.g., https://instance.service-now.com/login_**quebec**.do). However, this is not always the case.

  3. "Help" Menu (in the UI):

    • In the ServiceNow UI, click on the "Help" icon (usually a question mark ? in the header).
    • Select "System Settings" or "About ServiceNow" (the exact wording may vary slightly depending on the release and configuration).
    • This will usually display a pop-up window or page with system information, including the ServiceNow release name and version.

  4. gs.getVersion() in Scripts (Server-Side):

    • You can use the server-side JavaScript API gs.getVersion() in a Business Rule, Script Include, or Background Script to programmatically get the ServiceNow version.
    • Example (in a Background Script): 
      gs.info("ServiceNow Version: " + gs.getVersion());
      This will print the ServiceNow version to the system logs.

  5. Instance Branding (Sometimes):

    • Some organizations customize their ServiceNow instance branding to include the release name in the header or footer. However, this is not a reliable method as it depends on custom branding.

The most reliable and recommended way to check the ServiceNow version is using the System Information page (System Diagnostics > System Information).

No Comments
Back to top
AI Summary