Baseline

What It Is

Baseline is ServiceNow's change detection mechanism that captures snapshots of unmodified out-of-box platform code before customizations occur. It creates reference points against which the upgrade process can compare current instance configurations to identify conflicts with incoming platform updates. When ServiceNow releases a new version, baseline comparisons reveal exactly which of your customizations will break, need modification, or can safely coexist with the new platform code. This prevents the nightmare scenario where an upgrade silently overwrites your business logic or creates runtime conflicts that surface weeks after go-live.

Architecturally, Baseline lives within the System Definition application as part of the platform's configuration management layer. It operates at the metadata level, tracking changes to business rules, script includes, UI policies, client scripts, and other platform objects that contain custom code or configuration. The baseline records are stored in the sys_baseline table family, creating parent-child relationships between baseline snapshots and individual configuration items. This allows the upgrade process to perform granular comparisons at the field level rather than treating entire records as monolithic units.

The baseline system integrates directly with ServiceNow's upgrade execution environment, feeding conflict detection algorithms that run during preview upgrades and live upgrade processes. When you initiate an upgrade preview, the system compares your current configuration against three data points: the original baseline snapshot, your current customized state, and the incoming platform changes. This three-way merge analysis determines whether conflicts exist and categorizes them by severity. The upgrade process relies on baseline data to populate conflict resolution interfaces, showing you exactly what changed between versions and what decisions you need to make about your customizations.

You cannot successfully manage enterprise ServiceNow upgrades without baseline functionality in several critical scenarios. Multi-application instances with extensive customizations require baseline snapshots to identify which applications contain conflicts and prioritize remediation efforts across development teams. Regulated environments where change documentation is mandatory need baseline reports to demonstrate exactly what platform changes will affect custom business logic. Organizations with complex integration layers depend on baseline conflict detection to prevent upgrades from breaking API customizations or middleware connections. Most critically, any instance where custom code extends or modifies OOB business rules, workflows, or UI components will experience undefined behavior during upgrades without baseline conflict resolution.

Platform owners and lead developers manage baseline strategy and execution, while individual application developers consume baseline conflict reports during upgrade cycles. Platform owners decide when to capture baselines, configure baseline policies for different application types, and coordinate baseline updates across development teams. Application developers use baseline conflict reports to understand how platform changes affect their customizations and implement necessary modifications. System administrators typically don't interact with baseline functionality directly but rely on baseline-generated reports to schedule upgrade windows and communicate change impacts to business stakeholders.

Vancouver introduced automated baseline capture for scoped applications, reducing manual baseline management overhead and improving conflict detection accuracy for custom applications. Xanadu expanded baseline functionality to include UI Builder components and Flow Designer elements, addressing gaps in previous versions where custom portal pages and flow customizations weren't properly tracked. The Washington release enhanced baseline reporting with impact analysis features that predict downstream effects of upgrade conflicts, helping teams prioritize remediation efforts based on business process criticality.

Where to Find and Configure It

Access baseline management through System Definition > Baseline where you create, view, and manage baseline snapshots for your instance. Navigate to System Upgrade > Upgrade History to view baseline conflict reports from previous upgrades and understand resolution patterns. Use System Applications > My Company Applications to configure automatic baseline capture settings for scoped applications.

Within Studio, access baseline functionality through Application Explorer > Baseline to capture application-specific baselines during development cycles. App Engine Studio provides baseline access under App Settings > Version Control for citizen developer applications. View baseline data in action through the sys_baseline table and related sys_baseline_item records that contain the actual snapshot data.

How It Works Step by Step

Baseline operates through a three-phase process: capture, comparison, and conflict resolution. During the capture phase, ServiceNow creates cryptographic hashes of configuration items in their out-of-box state, storing these signatures alongside complete field-level snapshots. The system tracks not just the final configuration but also metadata about when the baseline was created, which platform version it represents, and what scope it covers. This creates an immutable reference point that upgrade processes can trust as the source of truth for OOB behavior.

The comparison phase executes during upgrade previews and live upgrades, analyzing differences between baseline snapshots, current configurations, and incoming platform changes. ServiceNow's comparison algorithms perform field-level analysis to determine whether customizations conflict with platform updates or can coexist safely. This analysis considers inheritance relationships, dependency chains, and execution order to predict runtime behavior after the upgrade. The system categorizes conflicts by type—direct overwrites, logic conflicts, or dependency breaks—and severity level to help teams prioritize remediation efforts.

The Execution Order

1. Baseline capture job scans configuration items within specified scope (application, table, or global)
2. System creates SHA-256 hash of each configuration item's field values and stores in sys_baseline_item
3. Parent baseline record in sys_baseline links all captured items with timestamp and platform version
4. During upgrade preview, comparison engine loads baseline data and current configuration state
5. System performs three-way comparison: baseline vs. current vs. incoming platform changes
6. Conflict detection algorithms analyze field-level differences and dependency relationships
7. Results populate conflict resolution interface with specific recommendations and impact analysis

// Create baseline for custom application scope
var baseline = new GlideRecord('sys_baseline');
baseline.name = 'Custom ITSM App - Pre-Vancouver';
baseline.description = 'Baseline before Vancouver upgrade';
baseline.scope = 'x_12345_custom_itsm';
baseline.baseline_type = 'application';
baseline.state = 'in_progress';
var baselineId = baseline.insert();

// Capture configuration items within scope
var configItems = new GlideRecord('sys_db_object');
configItems.addQuery('scope', 'x_12345_custom_itsm');
configItems.query();
while (configItems.next()) {
    var baselineItem = new GlideRecord('sys_baseline_item');
    baselineItem.baseline = baselineId;
    baselineItem.table = configItems.name;
    baselineItem.sys_id = configItems.sys_id;
    baselineItem.hash = gs.generateHash(configItems);
    baselineItem.insert();
}

Real-World Scenarios

Detecting Custom Business Rule Conflicts During Platform Upgrade

Your organization has extensively customized incident assignment business rules to integrate with external workforce management systems. The upcoming platform upgrade includes ServiceNow's new assignment engine that modifies the same OOB business rules your team customized two years ago.

Navigate to System Definition > Baseline and create a new baseline named 'Pre-Upgrade Assignment Rules' with scope set to Global and type Business Rules. Execute the baseline capture, then run your upgrade preview. The conflict report will show exactly which assignment business rules contain customizations that conflict with the new platform assignment engine, allowing you to create preservation rules or modify your custom logic before the live upgrade.

Watch for false positives where ServiceNow flags business rules that reference updated API methods but don't actually conflict functionally. The baseline comparison can't distinguish between breaking changes and backward-compatible platform enhancements, so review each conflict manually. Also monitor execution order dependencies—your custom assignment rules might work individually but fail when the platform changes the sequence of OOB assignment business rules.

Baseline Tracking for Multi-Application Development Environment

Your development team manages twelve custom scoped applications across HR, Finance, and Operations domains, each with different development cycles and upgrade schedules. You need baseline snapshots that allow independent upgrade testing per application while maintaining visibility into cross-application dependencies.

Configure automatic baseline capture by navigating to each application in System Applications > My Company Applications and enabling Automatic Baseline Capture with frequency set to Weekly. Create a master baseline capture scheduled script that iterates through all custom applications and creates coordinated baseline snapshots before each platform upgrade cycle. This provides application-specific conflict reports while maintaining timeline synchronization across development teams.

Pay attention to baseline storage consumption—automatic capture across multiple applications can generate significant database overhead over time. Configure baseline retention policies to automatically purge snapshots older than six months unless they're marked as upgrade reference points. Cross-application dependencies won't appear in individual application baseline reports, so supplement with periodic global baseline captures that reveal integration conflicts between your custom applications.

The Classic Mistake

The wrong approach is modifying baseline records in place. Admins see a Business Rule in System Definition > Business Rules that needs adjustment, open it, and directly edit the Script field or Condition field. They save the record thinking they've made a clean customization. The sys_update_version table shows their change as an update to the existing record, not a new customization.

This fails because during upgrades, ServiceNow cannot distinguish between your intentional customizations and baseline code that needs updating. The upgrade process sees your modified baseline record and either overwrites your changes completely or creates a merge conflict that breaks functionality. Users experience unexpected behavior or complete failure of business logic after upgrades. ServiceNow internally treats your modification as a corruption of the baseline rather than a legitimate customization, so the platform has no mechanism to preserve your intent during version updates.

// Create NEW Business Rule: "Custom - Incident State Logic"
// Table: incident
// When: before
// Order: 200 (after baseline rules)
// Active: true
// Condition: state.changes() && state == 6

(function executeRule(current, previous) {
    // Override baseline resolution behavior
    if (gs.nil(current.resolved_at)) {
        current.resolved_at = gs.nowDateTime();
    }
    
    // Custom notification logic
    gs.eventQueue('incident.resolved.custom', current);
    
    // Deactivate baseline rule by setting Active=false
    // on sys_script with name="Incident Resolution Handler"
})(current, previous);

When to Use This vs Alternatives

Baseline comparison is essential when you need to maintain upgrade safety while implementing customizations that modify or extend out-of-box functionality. It's the correct approach when you're building on ServiceNow's existing foundation rather than creating completely new functionality from scratch.

When Baseline is the Right Choice

Use baseline comparison when modifying Business Rules, UI Policies, Client Scripts, or Workflows that extend existing ServiceNow processes. Custom scoped applications can't provide this upgrade safety because they don't track what you've overridden from the global scope. Update Sets alone are insufficient because they don't show you the original baseline state that your changes are replacing.

When to Use Scoped Applications Instead

Choose scoped applications when building completely new functionality that doesn't override existing ServiceNow behavior. If you're creating new tables, new workflows for custom processes, or new Service Catalog items, scoped apps provide better encapsulation and don't require baseline tracking. Scoped applications also make sense when you need to distribute your customization across multiple instances as a reusable package.

When You Need Both Approaches

Use baseline comparison for overriding existing platform behavior while building new functionality in scoped applications. For example, modify global Business Rules to integrate with your scoped application's custom tables, while keeping the new business logic contained within the scoped app. This approach gives you upgrade safety for your overrides and clean encapsulation for your new features.

Platform Interactions & Side Effects

• Update Set capture automatically records baseline comparisons in sys_update_version with the payload field containing XML diff data between baseline and current state
• Upgrade processes write conflict detection results to sys_upgrade_history and sys_upgrade_history_log when baseline comparisons identify customized records
• Business Rules and Script Includes with baseline modifications bypass the script cache, causing performance degradation until the next cache refresh cycle
• ACL inheritance breaks when baseline Access Controls are modified directly rather than being overridden with new records at higher specificity levels
• Instance cloning preserves baseline comparison data but may reset sys_update_version.source references, breaking upgrade conflict detection
• Email Notifications and Workflow activities reference baseline Script Includes that may fail silently if baseline modifications introduce syntax errors
• Dictionary overrides create entries in sys_dictionary_override that can conflict with baseline schema changes during major version upgrades
• Transform Maps and Import Sets fail when baseline field mappings are modified and the source data structure changes in subsequent ServiceNow releases
• Plugin activation and deactivation can restore baseline versions of customized records, overwriting modifications without warning
• ServiceNow Store application installations check for baseline conflicts and may refuse to install if critical system records have been modified

Debugging and Troubleshooting

The most common failure symptom is unexpected behavior after upgrades where customizations either disappear completely or partially work. Admins see Business Rules that appear active but don't execute, or UI Policies that work in some contexts but fail in others. Users experience inconsistent application behavior, such as forms that validate correctly sometimes but allow invalid data through in specific scenarios.

Check the System Log > All for "Baseline comparison failed" or "Update conflict detected" messages. Navigate to System Update Sets > Retrieved Update Sets to find upgrade conflicts marked with red warning icons. The sys_upgrade_history_log table contains detailed conflict resolution logs showing exactly which fields were overwritten during upgrades.

Look for error messages like "Record has been modified since baseline" or "Unable to merge changes from baseline version" in upgrade logs. The Script Debugger shows "Baseline script version mismatch" when Business Rules or other scripts fail to load properly. System Properties glide.upgrade.strict_mode controls whether baseline conflicts block upgrades entirely or just generate warnings.

Diagnostic Checklist:

• Query sys_update_version for records where source field is empty but type is 'Business Rule' or 'Script Include'
• Check if modified records have sys_package set to 'Global' indicating dangerous baseline modifications
• Compare sys_created_on and sys_updated_on timestamps on suspected baseline records - they should match for unmodified OOB items
• Verify sys_updated_by shows 'system' for baseline records, not a user account
• Test functionality in a fresh sub-production instance to confirm if behavior is baseline or customized
• Review sys_upgrade_history table filtered by state='Conflict' to identify upgrade-related issues
• Enable debug logging for com.glide.update and com.glide.upgrade to capture detailed baseline comparison operations

Quick Reference

• Baseline records always have sys_created_by and sys_updated_by set to 'system' - any user name indicates customization
• Maximum baseline comparison payload size is 1MB - larger customizations get truncated and lose upgrade safety
• ServiceNow stores baseline data for exactly 2 major versions - older customizations become untrackable during upgrades
• Dictionary field sys_scope value of 'global' with a populated sys_update_name indicates a baseline record that can be safely overridden
• Plugin-provided records reset to baseline when the plugin is reactivated, regardless of customizations made
• Baseline comparison uses XML serialization - special characters in scripts can corrupt the comparison and cause false conflicts
• Update Set preview shows baseline conflicts but committing the Update Set may silently overwrite conflicting customizations
• Clone operations preserve sys_update_version records but may not maintain proper baseline linkage for upgrade detection
• System property glide.update.synch.batch_size default value of 1000 controls how many baseline comparisons process simultaneously during upgrades
• ATF test failures after upgrades often trace to baseline Business Rule modifications that changed execution order or conditions