2.2 Instance Configuration

Why Instance Configuration Matters

Quick Answer: An instance is a self-contained ServiceNow environment with its own database and URL. Administrators tune instance behavior with system properties, change look-and-feel through branding settings, add features by activating plugins and Store applications, and promote changes between instances with Update Sets or source control.

Instance Configuration is about 10% of the CSA exam — a higher weight than navigation. The exam expects you to know where a setting lives and how a change safely travels from a development instance to production.

Instances and Nodes

These two terms are frequently confused on the exam.

Key point: data is per instance, not per node. Adding nodes scales processing; it does not create a separate copy of data. Customers do not share an instance with other customers.

Branding and UI Settings

Branding is configured with System Properties and related records, not by editing core code.

• Basic Configuration UI (System Properties or the guided setup banner) sets the browser tab title, banner image / company logo, header colors, and the page footer.
• The Company record (core_company) stores the organization name and logo used in some areas.
• Themes control the color palette; Next Experience uses the Polaris theme system, while UI16 uses CSS-based themes.
• The system property glide.product.description and related banner properties affect text shown across the instance.

Good practice: brand non-production instances differently (for example, a red banner on dev) so users instantly recognize where they are.

System Properties

System properties are name/value records stored in the sys_properties table. They control instance-wide behavior — from enabling a feature to setting a default time zone. Administrators reach them through:

• System Properties application modules (categorized property pages), or
• Navigating directly to sys_properties.list (requires elevated access), or
• The Basic Configuration UI for common branding values.

Changing a property takes effect for the whole instance. Some properties are cached, so a change may require a short cache flush before it is visible. Properties are configuration data and travel in Update Sets when captured.

Plugins and Store Applications

Plugins are packaged units of platform functionality. Activating a plugin can create tables, roles, properties, and demo data.

• Activated from System Definition > Plugins (or System Applications > All Available Applications).
• Some plugins are not reversible once activated — the exam expects you to know that plugin activation should be tested in a sub-production instance first.
• Some plugins include optional demo data you can choose to load.

Store applications are packaged apps from the ServiceNow Store. They install at the instance level, are versioned, and are typically delivered in their own application scope.

Moving Changes: Update Sets vs Source Control

This is one of the most exam-relevant topics in this domain.

Update Sets

An Update Set is a group of customizations (configuration records) captured so they can be moved from one instance to another (for example, dev to test to prod).

• You set a current Update Set; subsequent tracked configuration changes are recorded into it.
• The flow is export/retrieve, preview, commit: retrieve the set on the target, preview to detect collisions, resolve, then commit.
• Update Sets capture configuration, not data. Records like incidents or users are not moved by Update Sets — use import or data tools for data.
• Local administrators promote work with Update Sets when a full Git pipeline is not in place.

Source Control

Source control links a scoped application to a Git repository (for example, GitHub). The app can be committed, branched, and applied across instances through the repository.

Localization and Time Zones

ServiceNow supports global teams.

• Internationalization (I18N) plugins add language packs; activated languages let users pick a display language in their profile.
• The system time zone is an instance-wide default, but each user can set their own time zone in their profile; date/time fields display in the user's time zone while being stored in a normalized form.
• Localization Framework helps translate field labels, choices, and notifications.

Exam tip: if two users see different times for the same record, the cause is usually their individual user time zone setting, not corrupted data.