ServiceNow Business Rules

1 What is a Business Rule?

If you're new to ServiceNow development, understanding Business Rules is fundamental. According to the official ServiceNow documentation, Business Rules automate and enforce business logic or policies whenever data changes in a table.

Business Rules are stored in the sys_script table and can be accessed via System Definition > Business Rules in the navigator. They're the backbone of server-side automation in ServiceNow, running regardless of how data is modified - whether through the UI, APIs, imports, or scripts.

Key Characteristics

• Server-Side Execution: Runs on the ServiceNow server, not in the user's browser
• Database Triggers: Executes when database operations occur (insert, update, delete, query)
• Universal Application: Runs regardless of how data is modified (UI, API, script, import)
• Access to Server APIs: Can use GlideRecord, GlideSystem, and other server-side APIs
• Condition-Based: Can include conditions to control when the script executes

2 Four Types of Business Rules

ServiceNow provides four distinct types of Business Rules, each designed for specific use cases based on when they execute relative to database operations. Understanding these types is crucial for effective ServiceNow development.

3 Before Business Rules

Before Business Rules execute before the record is saved to the database. They're ideal for data validation, field manipulation, and controlling whether an operation should proceed.

Key Characteristics

• No current.update() needed: Changes made to the current record are automatically saved when all Before BRs complete
• Can abort operations: Use current.setAbortAction(true) to prevent insert/update/delete
• Access to previous values: The previous object contains the record's state before modification
• Synchronous execution: Blocks the transaction until complete

Example 1: Auto-Populate Fields

(function executeRule(current, previous /*null when async*/) {
    // Auto-populate assignment group based on category
    if (current.category == 'network') {
        current.assignment_group.setDisplayValue('Network Team');
    } else if (current.category == 'hardware') {
        current.assignment_group.setDisplayValue('Hardware Support');
    }

    // Set priority based on urgency and impact
    if (current.urgency == 1 && current.impact == 1) {
        current.priority = 1; // Critical
    }

    // No current.update() needed - changes save automatically
})(current, previous);

Example 2: Date Validation with Abort

Use setAbortAction() to prevent invalid operations. As noted in the ServiceNow Community forum, this is essential for server-side validation:

(function executeRule(current, previous /*null when async*/) {
    // Validate that end date is after start date
    if ((!current.u_start_date.nil()) && (!current.u_end_date.nil())) {
        var start = current.u_start_date.getGlideObject().getNumericValue();
        var end = current.u_end_date.getGlideObject().getNumericValue();

        if (start > end) {
            gs.addErrorMessage('Start date must be before end date');
            current.u_start_date.setError('Invalid date range');
            current.setAbortAction(true);
        }
    }
})(current, previous);

Example 3: Prevent Unauthorized State Changes

(function executeRule(current, previous /*null when async*/) {
    // Prevent closing incident without resolution notes
    if (current.state == 6) { // Resolved
        if (current.close_notes.nil()) {
            gs.addErrorMessage('Resolution notes are required before closing');
            current.setAbortAction(true);
        }
    }

    // Prevent reopening after 30 days
    if (current.state.changes() && previous.state == 7) { // Was Closed
        var closedDate = previous.closed_at.getGlideObject();
        var now = new GlideDateTime();
        var daysDiff = gs.dateDiff(closedDate.getValue(), now.getValue(), true);

        if (Math.abs(daysDiff) > 30) {
            gs.addErrorMessage('Cannot reopen incidents closed more than 30 days ago');
            current.setAbortAction(true);
        }
    }
})(current, previous);

4 After Business Rules

After Business Rules execute after the record is saved to the database. They run synchronously, meaning the user must wait for them to complete before the transaction finishes.

Key Characteristics

• Record already saved: The current record exists in the database with a sys_id
• current.update() required: If modifying the current record, you must call current.update()
• Synchronous: Blocks user interaction until complete
• Best for related records: Ideal for updating records on other tables

Example 1: Create Related Task

(function executeRule(current, previous /*null when async*/) {
    // When a high priority incident is created, auto-create a problem task
    if (current.priority == 1 && current.operation() == 'insert') {
        var problem = new GlideRecord('problem');
        problem.initialize();
        problem.short_description = 'Investigate: ' + current.short_description;
        problem.description = 'Auto-created from critical incident: ' + current.number;
        problem.u_related_incident = current.sys_id;
        problem.assignment_group = current.assignment_group;
        problem.insert();

        // Log the created problem
        gs.info('Created Problem ' + problem.number + ' for Incident ' + current.number);
    }
})(current, previous);

Example 2: Update Parent Record

(function executeRule(current, previous /*null when async*/) {
    // Update parent change request when all tasks are complete
    if (current.state == 3) { // Closed Complete
        var parent = new GlideRecord('change_request');
        if (parent.get(current.parent)) {
            // Check if all child tasks are complete
            var openTasks = new GlideAggregate('change_task');
            openTasks.addQuery('parent', current.parent);
            openTasks.addQuery('state', '!=', 3);
            openTasks.addQuery('sys_id', '!=', current.sys_id);
            openTasks.addAggregate('COUNT');
            openTasks.query();

            if (openTasks.next() && openTasks.getAggregate('COUNT') == 0) {
                parent.state = 3; // Move to Review
                parent.update();
            }
        }
    }
})(current, previous);

5 Async Business Rules

Async Business Rules run asynchronously in the background after the database operation completes. According to the ServiceNow performance guidelines, they're queued by the scheduler and run as soon as resources are available.

Key Characteristics

• Non-blocking: User can continue working immediately after form submission
• Scheduler-based: Jobs appear in System Scheduler > Scheduled Jobs as "ASYNC: [BR Name]"
• Priority field matters: Determines execution order in the queue (100, 200, 300, etc.)
• Caution with Delete: If triggered on delete, the record won't exist when the script runs

When to Use Async Instead of After

Example: External API Integration

(function executeRule(current, previous /*null when async*/) {
    // Send critical incident to external monitoring system
    if (current.priority == 1) {
        try {
            var request = new sn_ws.RESTMessageV2('External_Monitor', 'POST_Alert');
            request.setStringParameter('incident_number', current.number);
            request.setStringParameter('description', current.short_description);
            request.setStringParameter('priority', current.priority.getDisplayValue());

            var response = request.execute();
            var httpStatus = response.getStatusCode();

            if (httpStatus == 200) {
                gs.info('Successfully sent alert for ' + current.number);
            } else {
                gs.error('Failed to send alert: ' + response.getBody());
            }
        } catch (ex) {
            gs.error('Exception sending alert: ' + ex.message);
        }
    }
})(current, previous);

Example: Email with Attachment Processing

(function executeRule(current, previous /*null when async*/) {
    // Process attachments after they're fully uploaded
    // Using Async ensures attachments are available

    var attachments = new GlideRecord('sys_attachment');
    attachments.addQuery('table_name', 'incident');
    attachments.addQuery('table_sys_id', current.sys_id);
    attachments.query();

    var attachmentList = [];
    while (attachments.next()) {
        attachmentList.push(attachments.file_name.toString());
    }

    if (attachmentList.length > 0) {
        // Queue event for email notification with attachment info
        gs.eventQueue('incident.attachments_added', current,
            attachmentList.join(', '),
            attachmentList.length.toString());
    }
})(current, previous);

6 Display Business Rules & g_scratchpad

Display Business Rules execute when a record is loaded for viewing on a form - after data is read from the database but before it's displayed to the user. Their primary purpose is passing server-side data to client scripts via the g_scratchpad object.

Understanding g_scratchpad

The g_scratchpad object is a bridge between server and client. It's a one-directional process (server to client) that eliminates the need for expensive AJAX calls.

Example 1: Check User Group Membership

Display Business Rule:

(function executeRule(current, previous /*null when async*/) {
    // Check if current user is member of VIP Support group
    var groupSysId = 'd625dccec0a8016700a222a0f7900d06'; // VIP Support group
    g_scratchpad.isVIPSupport = gs.getUser().isMemberOf(groupSysId);

    // Also pass user's department
    g_scratchpad.userDepartment = gs.getUser().getDepartmentID();

    // Pass calculated field not on the form
    g_scratchpad.daysSinceCreated = gs.dateDiff(current.sys_created_on,
        gs.nowDateTime(), true);
})(current, previous);

Client Script (onLoad):

function onLoad() {
    // Show/hide VIP-only fields based on group membership
    if (g_scratchpad.isVIPSupport) {
        g_form.setDisplay('u_vip_notes', true);
        g_form.setDisplay('u_escalation_path', true);
    } else {
        g_form.setDisplay('u_vip_notes', false);
        g_form.setDisplay('u_escalation_path', false);
    }

    // Show age warning for old records
    if (parseInt(g_scratchpad.daysSinceCreated) > 30) {
        g_form.showFieldMsg('state',
            'This record is over 30 days old', 'warning');
    }
}

Example 2: Pass Parent Record Data

Display Business Rule (on problem_task table):

(function executeRule(current, previous /*null when async*/) {
    // Pass parent problem details to form
    var gr = new GlideRecord('problem');
    if (gr.get(current.parent)) {
        g_scratchpad.parentProblem = current.parent.toString();
        g_scratchpad.parentShortDesc = gr.short_description.toString();
        g_scratchpad.parentAssignedTo = gr.assigned_to.toString();
        g_scratchpad.parentAssignmentGroup = gr.assignment_group.toString();
    }
})(current, previous);

Client Script (onLoad):

function onLoad() {
    // Auto-populate fields from parent on new record
    if (g_form.isNewRecord() && g_scratchpad.parentProblem) {
        g_form.setValue('short_description',
            'Task for: ' + g_scratchpad.parentShortDesc);
        g_form.setValue('assigned_to', g_scratchpad.parentAssignedTo);
        g_form.setValue('assignment_group', g_scratchpad.parentAssignmentGroup);
    }
}

7 Query Business Rules

Before Query Business Rules are a special type that execute before every query on a table. According to the ServiceNow performance best practices, they can add filters to control which records users can access, making them powerful but potentially performance-impacting.

Key Characteristics

• Runs on every query: Executes whether data access is via UI, script, API, or import
• Data segregation: Used to limit what records users can access
• Performance impact: Can significantly affect system performance if not optimized
• Not for security: Use ACLs for security; Query BRs are for filtering

Example: Filter by User's Company

(function executeRule(current, previous /*null when async*/) {
    // Only show records belonging to user's company
    var userCompany = gs.getUser().getCompanyID();

    if (userCompany) {
        current.addQuery('company', userCompany);
    }
})(current, previous);

Best Practices for Query BRs

• Add app-tier caching: Cache frequently accessed data to reduce database load
• Ensure proper indexes: Work with your DBA to ensure supporting indexes exist
• Limit scope: Add conditions to the BR to limit when it runs
• Don't disable ACLs: Use Query BRs to supplement, not replace, ServiceNow's built-in security

8 Execution Order & Priority

Understanding execution order is crucial for debugging and avoiding conflicts. According to the ServiceNow Community, business rules apply consistently regardless of whether records are accessed through forms, lists, or web services. However, Display business rules only run when viewing forms.

When Does Each Business Rule Type Execute?

Each Business Rule type responds to specific database operations. Use the checkboxes in the "When to run" tab to configure which operations trigger your rule:

Execution Flow Diagram

Complete Execution Sequence

When a form is submitted, here's the detailed execution order:

Understanding the Order Field

The Order field determines execution sequence among Business Rules of the same type. Lower values execute first. The default is 100, and the magic number 1000 is when ServiceNow engines (workflows, approvals) run.

Priority Field (Async Only)

For Async Business Rules, there are two relevant fields:

• Order: Determines when the BR is queued in the scheduler
• Priority: Determines execution priority within the queue (100, 200, 300, etc.)

9 Business Rules vs GlideRecord: Understanding the Difference

A common point of confusion for ServiceNow beginners is understanding the relationship between Business Rules and GlideRecord. They are fundamentally different concepts that work together.

Business Rule vs GlideRecord Comparison

How They Work Together

Think of it this way: A Business Rule is the "container" that defines when your automation runs, and GlideRecord is the "tool" you use inside that container to work with data.

// This is a BUSINESS RULE (the automation container)
// It runs AFTER an incident is updated

(function executeRule(current, previous) {
    // Inside the BR, we use GLIDERECORD (the database API)
    // to create a related task

    var task = new GlideRecord('task');  // GlideRecord API
    task.initialize();
    task.short_description = 'Follow-up for ' + current.number;
    task.parent = current.sys_id;
    task.insert();  // GlideRecord method

})(current, previous);

The 'current' Object

In Business Rules, current is a special GlideRecord object that represents the record being processed. You don't need to query for it - ServiceNow provides it automatically:

(function executeRule(current, previous) {
    // 'current' IS a GlideRecord - no need to create one!
    // It already contains the record being inserted/updated

    current.priority = 1;  // Modify the current record
    current.assignment_group.setDisplayValue('Network Team');

    // For Before BRs: changes save automatically
    // For After BRs: would need current.update() (but avoid this!)

})(current, previous);

When to Use GlideRecord in Business Rules

• Query other tables: Look up related records, validate against other data
• Create new records: Auto-generate tasks, problems, or child records
• Update related records: Cascade changes to parent/child records
• Aggregate data: Count, sum, or calculate across multiple records

Quick GlideRecord Reference for BRs

// QUERY: Find records
var gr = new GlideRecord('incident');
gr.addQuery('priority', 1);
gr.query();
while (gr.next()) { /* process */ }

// INSERT: Create new record
var gr = new GlideRecord('task');
gr.initialize();
gr.short_description = 'New task';
gr.insert();

// UPDATE: Modify existing records
var gr = new GlideRecord('incident');
gr.addQuery('state', 1);
gr.query();
while (gr.next()) {
    gr.state = 2;
    gr.update();  // Required for GlideRecord updates
}

// COUNT: Use GlideAggregate (more efficient!)
var ga = new GlideAggregate('incident');
ga.addAggregate('COUNT');
ga.query();
if (ga.next()) {
    var count = ga.getAggregate('COUNT');
}

10 Best Practices & Common Pitfalls

Following best practices is essential for maintaining a performant and maintainable ServiceNow instance. These guidelines come from Quality Clouds and the ServiceNow Community.

Use Declarative Actions When Possible

Before writing custom scripts, consider using ServiceNow's built-in Actions tab for simple field value assignments. Declarative actions are easier to maintain, less error-prone, and don't require scripting knowledge.

Critical Do's

• Use conditions: Always add conditions to limit when BRs execute
• Use Async for long operations: External APIs, emails, heavy processing
• Use Before for validation: Data checks, field population, abort actions
• Use After for related records: Updating other tables after save
• Add error handling: Try-catch blocks for external integrations
• Log appropriately: Use gs.info() for tracking, gs.error() for failures

Critical Don'ts

// BAD - Don't do this in Before BR
current.state = 2;
current.update(); // WRONG! Will cause recursion

// GOOD - Just set the value
current.state = 2;
// No update() needed - saves automatically

Preventing Recursion

If you must use current.update() in an After BR, prevent recursion with setWorkflow(false):

(function executeRule(current, previous) {
    // Only if absolutely necessary in After BR
    current.u_processed = true;
    current.setWorkflow(false); // Prevents recursive BRs
    current.update();
    current.setWorkflow(true); // Re-enable for future operations
})(current, previous);

Performance Optimization Checklist

11 Debugging & Troubleshooting

Effective debugging is essential for ServiceNow developers. According to ServiceNow's debugging guide, Business Rules exceeding 100ms are automatically logged as slow. This section covers the logging functions, debugging tools, and troubleshooting techniques every developer should know.

GlideSystem Logging Functions

ServiceNow provides several logging functions through the gs (GlideSystem) object. Understanding when to use each is crucial for effective debugging:

Viewing Log Output

Log messages can be viewed in several locations depending on the logging function used:

• System Logs > All: View all gs.info(), gs.warn(), gs.error(), and gs.debug() output in the sys_log table
• Session Debug Output: When session debugging is enabled, messages appear at the bottom of forms and lists
• Script Debugger (New York+): The session log tab shows real-time output
• Node Log File Browser: Navigate to System Logs > Node Log File Browser for gs.log() and gs.print() output

Understanding Log Fields

According to ServiceNow KB2593531, log entries contain structured fields for effective debugging:

• _timestamp: Exact timestamp in UTC with microsecond precision
• _level: Severity level (INFO, DEBUG, ERROR, WARN)
• _message: The actual log content
• _txid: Transaction ID for correlating related log entries across components
• _session_id: Session identifier for tracking user activity
• _user / _logged_in_user: User context (shows impersonation when active)
• _system_id: Identifies which node generated the log

Session Debug for Business Rules

Session debugging is essential for seeing gs.debug() output and understanding Business Rule execution. According to the ServiceNow Developer Blog:

• Enable Debug Business Rule: Navigate to System Diagnostics > Session Debug > Debug Business Rule
• Enable Debug Security: Also enable Debug Security to see ACL restrictions
• View Output: Debug messages appear at the bottom of forms and lists after you perform an action
• Before Query Rules: Debug output reveals query business rules that may be filtering records unexpectedly

Script Tracer

The Script Tracer provides detailed execution tracking for server-side scripts:

• Navigate to System Diagnostics > Script Tracer
• Click Start Tracer to begin capturing script activity
• Perform the transaction you want to trace
• Review results showing detailed execution logs, timing, and record changes

Transaction Logs

For performance analysis, use the Transaction Logs to identify slow Business Rules:

• Navigate to System Logs > Transactions (All users)
• Add columns: Business rule time, Browser time, Client response time, SQL time, ACL time
• Sort by "Business rule time" descending to find slow transactions
• Business Rules exceeding 100ms are flagged as slow

Debugging Code Example

Use this pattern for comprehensive debugging in your Business Rules:

(function executeRule(current, previous) {
    var BR_NAME = 'MyBusinessRule';

    // Entry point logging
    gs.info('[' + BR_NAME + '] Starting - Table: ' + current.getTableName() +
            ', Record: ' + current.getUniqueValue());

    try {
        var startTime = new Date().getTime();

        // Debug level for detailed tracing (requires session debug)
        gs.debug('[' + BR_NAME + '] Field values - state: ' + current.state +
                 ', priority: ' + current.priority);

        // Your business logic here
        // ...

        var endTime = new Date().getTime();
        gs.info('[' + BR_NAME + '] Completed in ' + (endTime - startTime) + 'ms');

    } catch (ex) {
        // Always log errors with stack trace
        gs.error('[' + BR_NAME + '] Error: ' + ex.message);
        gs.error('[' + BR_NAME + '] Stack: ' + ex.stack);
    }
})(current, previous);

Common Troubleshooting Checklist

If your Business Rule isn't executing or logging, check these common issues:

• Is it Active? Verify the "Active" checkbox is checked
• Correct Table? Ensure the Business Rule is on the right table
• When to Run? Check that Insert/Update/Delete/Query checkboxes match your scenario
• Conditions Met? Remove all conditions temporarily to test if the rule fires
• Scoped App? Replace gs.log() with gs.info() in scoped applications
• Log Filters? Clear the "Source" filter in System Logs > All to see all entries
• Session Debug? Enable session debugging to see gs.debug() output

12 Business Rules vs Client Scripts vs UI Policies

Choosing the right scripting mechanism is crucial. According to the ServiceNow Community discussion, each has specific use cases.

Quick Decision Guide

13 Common Interview Questions

Based on the ServiceNow Community's interview guide and real interview experiences, here are 30 frequently asked Business Rule questions organized by difficulty level:

Fundamental Questions (1-10)

1. What is a Business Rule in ServiceNow?
   A server-side script that runs when records are inserted, updated, deleted, displayed, or queried. Stored in sys_script table. (Q1)
2. What are the four types of Business Rules?
   Before, After, Async, and Display. Each runs at a different point relative to the database operation. (Q2)
3. Where are Business Rules stored?
   In the sys_script table. Access via System Definition > Business Rules. (Q3)
4. What's the difference between Before and After Business Rules?
   Before runs before database save (changes auto-save, no update() needed). After runs after save (update() required to modify current record). (Q4)
5. When does a Display Business Rule run?
   When a record is loaded for viewing on a form only. Does not run on list views, APIs, or during insert/update operations. (Q5)
6. What is the purpose of the "Active" checkbox?
   Controls whether the Business Rule executes. Unchecking it disables the rule without deleting it. (Q6)
7. What operations can trigger a Business Rule?
   Insert, Update, Delete, Query (for Query BRs), and Display (for Display BRs). (Q7)
8. What is the current object?
   A GlideRecord object representing the record being processed. Contains the new values during the transaction. (Q8)
9. What is the previous object?
   A GlideRecord object containing the record's values before modification. Only available in Before and After BRs on update operations. (Q9)
10. How do you check if a field value changed?
    Use current.field_name.changes() or compare current.field_name != previous.field_name. (Q10)

Intermediate Questions (11-20)

11. Why should you avoid using current.update() in Business Rules?
    It causes recursive execution where the rule triggers itself. Before BRs auto-save changes. After BRs should use current.setWorkflow(false) before update() to prevent recursion. (Q11)
12. What is g_scratchpad and how is it used?
    An object that passes data from Display BRs (server-side) to Client Scripts (client-side). Set values in Display BR, read them in onLoad Client Script. (Q12)
13. What does the Order field control?
    Execution sequence among BRs of the same type on the same table. Lower values run first. Default is 100. Order 1000 is when engines (workflows) execute. (Q13)
14. How do you prevent a record from being saved?
    Use current.setAbortAction(true) in a Before BR. Optionally add a message with gs.addErrorMessage(). (Q14)
15. What's the difference between Async and After Business Rules?
    After runs synchronously (blocks user until complete). Async runs in background via scheduler (non-blocking). Use Async for emails, external APIs, heavy processing. (Q15)
16. What is a Query Business Rule?
    Runs before every GlideRecord query on a table. Used to add automatic filters for row-level security. Use sparingly due to performance impact. (Q16)
17. How do you access related record data in a Business Rule?
    Use dot-walking (e.g., current.caller_id.email) or create a new GlideRecord query to fetch related records. (Q17)
18. What logging functions work in scoped applications?
    gs.info(), gs.debug(), gs.warn(), gs.error(). Note: gs.log() does NOT work in scoped apps. (Q18)
19. How do you prevent workflows from running when updating a record?
    Call current.setWorkflow(false) before the update operation. (Q19)
20. What is the difference between gs.nil() and checking for empty string?
    gs.nil() checks for null, undefined, and empty string. It's more comprehensive than == ''. (Q20)

Execution Order & Sequence Questions (21-25)

21. What is the complete execution order when a user submits a form?
    onSubmit Client Script → Before BR (Order < 1000) → Engines/Workflows (Order 1000) → Before BR (Order ≥ 1000) → Database Operation → After BR → Async BR (Q21)
22. If you have a Before BR, After BR, Workflow, and Async BR on the same table, what's the execution sequence on insert?
    Before BR → Workflow (at Order 1000) → Database Insert → After BR → Async BR (background). The user sees the response after After BR completes. (Q22)
23. A table has UI Policy, Client Script (onChange), Before BR, and After BR. User changes a field and saves. What's the order?
    onChange Client Script → UI Policy (field change) → onSubmit Client Script → Before BR → Database → After BR. UI Policy and Client Scripts run on client before server-side BRs. (Q23)
24. You have two Before BRs: one with Order 100, another with Order 500. Which runs first?
    Order 100 runs first. Lower order values execute before higher values. If both have the same order, execution sequence is not guaranteed. (Q24)
25. When do Query Business Rules execute relative to other automations?
    Query BRs run BEFORE the query returns results, before any form is displayed. They execute on every GlideRecord query, list view, report, or API call on that table. (Q25)

Advanced & Scenario Questions (26-30)

26. Can you call a Business Rule directly from a Client Script?
    No. Use GlideAjax to call a Script Include, which can contain similar server-side logic. Alternatively, use a Display BR with g_scratchpad for passing data to client. (Q26)
27. A Before BR sets a field value, and an After BR reads that same field. Will the After BR see the updated value?
    Yes. The Before BR changes are committed to the database before After BRs run. The current object in After BR reflects the saved state. (Q27)
28. You need to update a parent record when a child record is created. Should you use Before or After BR?
    After BR. The child record must exist in the database (have a sys_id) before you can reliably update the parent with a reference to it. (Q28)
29. How do you prevent infinite loops when an After BR updates the current record?
    Use current.setWorkflow(false) to prevent BRs from re-triggering, or add a condition checking current.operation() == 'update' with a specific field change. (Q29)
30. A Flow, Business Rule, and Workflow all exist on the same table. What's the execution order?
    Before BR → Flow Designer flows (run as part of engines at ~Order 1000) → Workflows → After BR → Async BR. Flows and Workflows run between Before and After BRs. (Q30)

14 Abbreviations & Glossary

Related Reading

Continue your ServiceNow learning journey with these related guides:

• ServiceNow GlideRecord CRUD Guide - Complete developer tutorial for database operations
• ServiceNow SPM Complete Guide - Strategic Portfolio Management
• ServiceNow ITSM Complete Guide - IT Service Management fundamentals
• CMDB Complete Guide 2025 - Configuration Management Database