ServiceNow = cloud-based IT Service Management (ITSM) platform
Delivery model: SaaS (Software as a Service)
Architecture: Instance-based (each customer gets own instance)

Key Modules:
┌─────────────────────────────────────────────┐
│  ITSM    → Incident, Problem, Change Mgmt   │
│  ITOM    → Discovery, Event Management       │
│  ITBM    → Project Portfolio Management      │
│  HRSD    → HR Service Delivery               │
│  CSM     → Customer Service Management       │
│  SecOps  → Security Operations               │
│  GRC     → Governance, Risk, Compliance      │
└─────────────────────────────────────────────┘

Why companies use ServiceNow:
- Single platform for IT and business workflows
- No-code/low-code workflow automation
- Built-in ITIL best practices
- 80%+ of Fortune 500 companies use it
- Strong reporting and SLA management

ServiceNow stores everything in tables (like database tables)

Core tables and their purposes:
┌──────────────────┬────────────────────────────┐
│ Table            │ Purpose                     │
├──────────────────┼────────────────────────────┤
│ incident         │ Incident records             │
│ change_request   │ Change management records    │
│ problem          │ Problem records              │
│ cmdb_ci          │ Configuration Items (CMDB)   │
│ sys_user         │ User records                 │
│ task             │ Parent table for all tasks   │
│ sc_request       │ Service Catalog requests     │
│ kb_knowledge     │ Knowledge Base articles      │
└──────────────────┴────────────────────────────┘

Key concept: Table inheritance
- task is the PARENT table
- incident, change_request, problem all EXTEND task
- Fields in task are inherited by child tables
- This is why incident has fields like "assigned_to",
  "priority", "state" — they come from task

# Check table hierarchy:
# System Definition → Tables → open any table
# Look at "Extends table" field

UI Policy (No-Code):
- Point-and-click configuration
- Controls field visibility, mandatory, read-only
- Runs on the CLIENT side (browser)
- No JavaScript required
- Best for: simple field behavior changes

Example: When Priority = 1 (Critical)
  → Make "Justification" field mandatory
  → Make "Assignment Group" mandatory
  → Show "Major Incident" checkbox

Client Script (JavaScript):
- Custom JavaScript code
- Runs on the CLIENT side (browser)
- Types:
  ┌──────────────┬──────────────────────────┐
  │ onChange      │ When a field value changes │
  │ onLoad       │ When form loads            │
  │ onSubmit     │ When form is submitted     │
  │ onCellEdit   │ When list cell is edited   │
  └──────────────┴──────────────────────────┘

Example (onChange):
function onChange(control, oldValue, newValue, isLoading) {
  if (isLoading || newValue === '') return;
  // When category changes to "Hardware"
  if (newValue === 'hardware') {
    g_form.setValue('subcategory', '');
    g_form.setMandatory('asset_tag', true);
  }
}

Rule of thumb:
→ Use UI Policy first (simpler, maintainable)
→ Use Client Script when UI Policy can't do it

Incident Management Lifecycle:

New → In Progress → On Hold → Resolved → Closed

Detailed flow:
┌─────────┐    ┌─────────────┐    ┌─────────┐
│   New   │───→│ In Progress │───→│On Hold  │
└─────────┘    └──────┬──────┘    └────┬────┘
                      │                │
                      ▼                │
               ┌──────────┐           │
               │ Resolved │←──────────┘
               └─────┬────┘
                     ▼
               ┌──────────┐
               │  Closed  │
               └──────────┘

Priority Matrix:
Priority = Impact × Urgency

         │ High    │ Medium  │ Low
─────────┼─────────┼─────────┼────────
High     │ P1-Crit │ P2-High │ P3-Mod
Medium   │ P2-High │ P3-Mod  │ P4-Low
Low      │ P3-Mod  │ P4-Low  │ P5-Plan

P1 (Critical): 1-hour response, 4-hour resolution
P2 (High):     4-hour response, 8-hour resolution
P3 (Moderate): 8-hour response, 24-hour resolution

SLA tracking is automatic based on priority

Three ITIL processes — different goals:

Incident Management:
  Goal: Restore service ASAP
  Focus: Speed of resolution
  Example: "Email server is down" → fix it NOW

Problem Management:
  Goal: Find the ROOT CAUSE
  Focus: Prevent recurrence
  Example: "Why does the email server keep crashing?"
  → Investigate → find memory leak → permanent fix

Change Management:
  Goal: Planned modification with minimal risk
  Focus: Controlled implementation
  Example: "Upgrade email server RAM from 16GB to 64GB"
  → CAB approval → scheduled maintenance window → deploy

Real-world scenario:
1. Server crashes at 2 AM → INCIDENT (restore service)
2. Investigation reveals memory leak → PROBLEM (root cause)
3. Decision to upgrade server → CHANGE (planned fix)

┌──────────┬──────────────┬──────────────────┐
│ Process  │ Trigger      │ Outcome          │
├──────────┼──────────────┼──────────────────┤
│ Incident │ Service down │ Service restored │
│ Problem  │ Recurring    │ Root cause found │
│ Change   │ Improvement  │ Controlled update│
└──────────┴──────────────┴──────────────────┘

GlideRecord = Server-side API for database operations
(ServiceNow's way of querying and manipulating records)

// Basic query: Get all P1 incidents assigned to a group
var gr = new GlideRecord('incident');
gr.addQuery('priority', 1);
gr.addQuery('assignment_group', 'Network Team');
gr.addQuery('state', '!=', 7); // Not closed
gr.orderByDesc('sys_created_on');
gr.query();

while (gr.next()) {
  gs.info('INC: ' + gr.number +
          ' | ' + gr.short_description +
          ' | State: ' + gr.state.getDisplayValue());
}

// Using encoded query (more efficient):
var gr = new GlideRecord('incident');
gr.addEncodedQuery('priority=1^assignment_group=Network Team^state!=7');
gr.query();

// Common methods:
gr.get('sys_id_value');     // Get single record by sys_id
gr.getValue('field_name');  // Get field value as string
gr.getDisplayValue('field');// Get display value
gr.getRowCount();           // Count matching records
gr.insert();                // Create new record
gr.update();                // Update current record
gr.deleteRecord();          // Delete current record

// NEVER do this in production:
// gr.query() without addQuery → loads ALL records

Business Rules = Server-side scripts that run when
records are displayed, inserted, updated, or deleted

Types:
┌──────────┬────────────────────────────────────┐
│ before   │ Runs BEFORE database operation      │
│          │ Use: validation, field manipulation  │
│          │ Can abort the operation              │
├──────────┼────────────────────────────────────┤
│ after    │ Runs AFTER database operation        │
│          │ Use: notifications, related updates  │
│          │ Record already saved                 │
├──────────┼────────────────────────────────────┤
│ async    │ Runs AFTER, in background            │
│          │ Use: heavy processing, integrations  │
│          │ Does not block the user              │
├──────────┼────────────────────────────────────┤
│ display  │ Runs when form is LOADED             │
│          │ Use: add dynamic info to form        │
│          │ Like onLoad but server-side          │
└──────────┴────────────────────────────────────┘

Example (before insert): Auto-assign based on category
(function executeRule(current, previous) {
  if (current.category == 'network') {
    current.assignment_group.setDisplayValue('Network Team');
    current.priority = 2;
  }
})(current, previous);

Example (after insert): Create a related task
(function executeRule(current, previous) {
  var task = new GlideRecord('task');
  task.initialize();
  task.short_description = 'Review: ' + current.number;
  task.parent = current.sys_id;
  task.insert();
})(current, previous);

Best practice: Use before for validation,
after for side effects, async for heavy work

GlideRecord: Row-by-row processing
- Loads EACH record into memory
- Good for: reading/updating individual records
- Bad for: counting or summing large datasets

GlideAggregate: Aggregate operations
- Performs COUNT, SUM, AVG, MIN, MAX at database level
- Does NOT load individual records
- Much better performance for reporting queries

// BAD: Counting with GlideRecord (loads all records)
var gr = new GlideRecord('incident');
gr.addQuery('priority', 1);
gr.query();
var count = gr.getRowCount(); // Loads ALL rows first!

// GOOD: Counting with GlideAggregate
var ga = new GlideAggregate('incident');
ga.addQuery('priority', 1);
ga.addAggregate('COUNT');
ga.query();
if (ga.next()) {
  var count = ga.getAggregate('COUNT');
  gs.info('P1 incidents: ' + count);
}

// SUM example: Total hours worked
var ga = new GlideAggregate('task');
ga.addAggregate('SUM', 'time_worked');
ga.groupBy('assignment_group');
ga.query();
while (ga.next()) {
  gs.info(ga.assignment_group.getDisplayValue() +
    ': ' + ga.getAggregate('SUM', 'time_worked'));
}

Rule: If you need COUNT/SUM/AVG → GlideAggregate
      If you need record data → GlideRecord

ServiceNow Integration Methods:

1. REST API (most common)
   - Inbound: External systems call ServiceNow REST APIs
   - Outbound: ServiceNow calls external REST APIs
   - Table API: /api/now/table/{tableName}
   - Scripted REST API: Custom endpoints

2. SOAP Web Services
   - Legacy integration method
   - Still used by older enterprise systems
   - WSDL-based

3. MID Server (for on-premise systems)
   - Java application installed on-premise
   - Acts as bridge between ServiceNow cloud
     and internal network
   - Used for: Discovery, Orchestration, JDBC

4. Import Sets + Transform Maps
   - Bulk data import from external sources
   - Import Set = staging table for incoming data
   - Transform Map = rules to map and transform
     data into target ServiceNow tables
   - Sources: JDBC, LDAP, CSV, Excel, REST

5. IntegrationHub (low-code)
   - Flow Designer actions for integrations
   - Pre-built spokes (Jira, Slack, Azure, AWS)
   - No scripting required for common integrations

// Outbound REST example:
var request = new sn_ws.RESTMessageV2();
request.setEndpoint('https://api.example.com/data');
request.setHttpMethod('GET');
request.setRequestHeader('Authorization', 'Bearer token');
var response = request.execute();
var body = response.getBody();
var httpStatus = response.getStatusCode();

Update Sets = mechanism to capture and transport
customizations between ServiceNow instances

How it works:
┌─────────┐    ┌─────────┐    ┌─────────┐
│   DEV   │───→│  TEST   │───→│  PROD   │
│Instance │    │Instance │    │Instance │
└─────────┘    └─────────┘    └─────────┘

Workflow:
1. Create Update Set in DEV
   - Name it descriptively: "PROJ-123_Incident_Form_Changes"
   - Set as current/default update set

2. Make your changes (captured automatically)
   - UI Policies, Business Rules, Client Scripts
   - Form layouts, ACLs, Workflows
   - NOT captured: data records, homepage layouts

3. Complete the Update Set
   - Mark as "Complete" when done
   - No more changes can be added

4. Retrieve in TEST instance
   - Retrieved Update Sets → pull from DEV
   - Preview: check for conflicts/errors
   - Commit: apply changes to TEST

5. Test and validate

6. Repeat for PROD

Collision handling:
- If same record modified in both instances
- Preview shows collision
- Options: Accept remote (overwrite), Skip, Merge

Best practices:
- One update set per feature/ticket
- Never modify Default update set
- Always preview before committing
- Back out plan: revert update set if issues