# Instance Administration and Troubleshooting

> Chapter 18 of the Courseiva SERVICENOW-CSA curriculum — https://courseiva.com/learn/servicenow-csa/instance-administration-and-troubleshooting

**Official objective:** 4.4 — Perform instance administration tasks and basic troubleshooting.

## Introduction

The exam domain 'Instance Administration and Troubleshooting' is where the SNOW-CSA exam tests your ability to keep the system healthy and fix common problems. This matters because a ServiceNow administrator is not just a button-pusher; they are the person who ensures the platform stays online, secure, and efficient. Without this knowledge, you cannot manage users, schedules, or even basic error messages.

## The Home Repair Logbook Analogy

When you call a plumber to fix a leaky pipe, what happens first is the plumber asks you what's wrong, and this leads to them looking at the problem and then writing down the fix in a logbook. That logbook is your record of every issue, every repair, and every part replaced. Without it, you'd have no idea which pipe was last fixed, what sealant was used, or why the water pressure suddenly dropped last month. Your ServiceNow instance works the same way. It's not just a piece of software floating in the cloud; it has a physical home (a data centre), it needs regular attention (updates and patches), and it keeps a log of everything that happens (system logs and diagnostic tools).

Now imagine you are a homeowner with a giant, complex house. You have an electrician, a roofer, a painter, and a security expert each working on different parts. You cannot manage them all by memory. You need one central place to track who did what, when, and what the result was. That's what instance administration is: the systematic care and record-keeping of your ServiceNow environment. And when something breaks — like the lights flickering (a performance issue) or the front door not locking (a security misconfiguration) — you need troubleshooting. That means methodically checking the logbook, running tests (like turning off one circuit at a time), and isolating the root cause before calling for help.

The key insight is that a ServiceNow instance is not magic. It runs on servers, uses a database, and is configured by humans. Just as your home's electrical system has a main panel with breakers, your instance has settings, plugins, and access controls. Troubleshooting is simply the process of figuring out which breaker tripped and why, using the logbook (the platform logs) and your understanding of how the house is wired (instance configuration).

## Core explanation

Instance administration is the set of tasks you perform to keep a ServiceNow instance running smoothly, securely, and efficiently. An 'instance' is simply your organisation's private copy of the ServiceNow platform hosted in the cloud. Think of it as a fully functional apartment you rent from ServiceNow — you control the furniture (configuration), but the building maintenance (server infrastructure) is handled by the landlord. Administration tasks include managing users, controlling access, scheduling backups, applying updates, and monitoring performance.

Troubleshooting is the systematic process of identifying, diagnosing, and resolving problems within that instance. A problem might be a slow page load, a user unable to log in, a scheduled job that failed, or an error message when creating a record. The goal is to find the root cause — the underlying reason for the symptom — and fix it.

Let's start with the fundamentals. Every ServiceNow instance has a graphical user interface (GUI) that administrators use to configure settings. This is accessed via a web browser. The main areas you need to know are:

- System Logs: These are the 'black box' of your instance. They record every error, warning, and informational message generated by the platform. The most important logs are the System Log (syslog), the Error Log, and the Transaction Log. If something goes wrong, you check these logs first.
- Scheduled Jobs: These are automated tasks that run at specific times, like sending daily email reminders or updating records. If a scheduled job fails, it might not be obvious until users complain. Troubleshooting jobs often means checking the job's history and log.
- Instance Properties: These are system-wide settings stored as key-value pairs. For example, there is a property called 'glide.platform.console.login.banner' that controls the message shown on the login page. Changing a property can sometimes fix a broken feature.
- Application Scope: Every customisation you create exists within a specific 'scope' (a namespace for your application). If you install an app from the ServiceNow Store, it installs into its own scope. Problems often arise when scopes conflict — two apps trying to modify the same table, for example.
- Database Views and Tables: ServiceNow stores all data in tables (like a spreadsheet). A 'table' is a set of records organised by columns. For example, the 'User' table stores all user accounts. Troubleshooting data issues often means checking if records exist, if they have the correct values, and if the table is configured correctly.

The most common administration tasks include:

- User Administration: Creating, updating, and deactivating user accounts. You also assign roles (like 'admin' or 'itil') that control what a user can see and do.
- Plugin Management: ServiceNow offers many optional features called 'plugins'. You must activate them to use the feature. For example, the 'Performance Analytics' plugin must be activated before you can create dashboards with graphs.
- System Maintenance: This includes applying the latest patches (called 'fixes') and upgrades. ServiceNow releases new versions twice a year (known as 'families'). Administrators must schedule and test these upgrades in a sub-production instance (a copy used for testing) before applying to production (the live instance used by real users).
- Backup and Restore: ServiceNow automatically backs up production instances daily. However, administrators can also create manual backups (called 'clones') of an instance for testing or recovery.

Troubleshooting follows a pattern. First, you identify the symptom (e.g., 'The portal is not loading'). Second, you collect data — check logs, ask users when it started, see if it's affecting all users or just one. Third, you form a hypothesis (e.g., 'Maybe a new plugin broke the portal'). Fourth, you test the hypothesis in a sub-production instance. Finally, you apply the fix (e.g., deactivating the plugin, restarting the instance, or reverting a configuration change).

A critical tool for troubleshooting is the 'Diagnostics' page, accessible from the 'System Diagnostics' module. It provides information about the instance's health, including memory usage, active sessions, and database performance. Another tool is the 'High Security Settings' which can block certain actions if misconfigured — a common cause of user lockouts.

Remember: instance administration replaces the old way of managing on-premise software, where you had to maintain your own servers. ServiceNow handles the hardware, but you are responsible for the configuration and operational health. Troubleshooting is your primary skill for keeping everything running.

## Real-world context

An IT professional, let's call her Priya, is the ServiceNow administrator for a mid-sized company. One Tuesday morning, she gets a call from the head of HR. 'Priya, the employee onboarding portal is broken. New hires cannot submit their IT requests. This is urgent — we have three people starting next week.' Priya does not panic. She knows exactly where to start.

First, she opens the instance in a browser and logs in with her admin account. She checks if she herself can access the portal. She can, which means the server is running and the network is fine. The problem is not a power outage or a cloud provider failure. She then asks the HR head: 'Is it just one user or everyone? When did it start? Any error messages?' The answer: 'All new hires are getting a blank page when they click the 'Submit Request' button. It started this morning.'

Priya now has a symptom: a blank page on a specific action. She navigates to the System Logs (specifically the Error Log) and filters by the time 'This morning'. She sees a repeated error: 'Invalid field name: u_department'. She recognises that 'u_department' is a custom field added to the 'Request' table last week. Her hypothesis: the new field was deleted or renamed by another administrator, and the form is now broken because it references a field that no longer exists.

She opens the 'System Definition > Tables' module and looks at the 'Request' table. She confirms that 'u_department' is missing from the list of columns. She checks the 'Audit History' for the table to see who deleted it. It was her colleague, Mark, who was 'cleaning up unused fields' yesterday. The problem is clear: the form still has a reference to the deleted field, causing a script error.

Priya now needs to fix the issue without breaking anything else. She takes the following steps:

- She opens a sub-production instance (a copy of production) and recreates the field 'u_department' with the exact same configuration (type: string, max length: 100).
- She then updates the form in the sub-production instance to remove any broken references and re-adds the field.
- She tests the portal flow in the sub-production instance — it works.
- She then applies the same fix to the production instance (re-creating the field and updating the form).
- She notifies the HR head that the portal is working again and sends a follow-up email to Mark explaining why deleting fields without checking dependent forms can cause issues.

Priya also sets up a 'Scheduled Job' to run a weekly scan of all tables for broken field references, so this problem will be caught early next time. She updates the instance documentation with a note about the incident.

This is a typical day for a ServiceNow administrator. It involves troubleshooting (identifying the blank page error, checking logs, finding the deleted field), administration (re-creating the field, updating forms, scheduling a preventive scan), and communication (talking to HR, following up with Mark). The tools used are the System Logs, the Table module, the Audit History, and sub-production instances.

## Exam focus

The SNOW-CSA exam tests 'Instance Administration and Troubleshooting' in a very specific way. You will NOT be asked to fix a real broken instance — that's what the practical labs are for. Instead, the exam gives you multiple-choice questions that describe a problem and ask you to choose the correct first step, the correct tool, or the correct configuration. The exam loves to test your understanding of where to look for information and what actions are safe to perform.

Concepts they love to test:

- System Logs: They will ask which log to check for a specific type of error. For example, 'A user reports a blank page when opening a record. Which log should you check first?' Answer: the Error Log.
- Scheduled Jobs: Questions about why a job failed, and how to check its history. They trap you by suggesting checking the job's 'Run As' user — if that user is inactive, the job will fail.
- Instance Properties: They might ask which property controls the session timeout duration. The answer is 'glide.ui.session_timeout'.
- Plugin Activation: They might present a scenario where a feature is not available (e.g., 'Knowledge is not showing up in the application navigator'). The correct answer is that the 'Knowledge Management' plugin needs to be activated.
- User Deactivation: They love to ask: 'What happens when you deactivate a user?' The correct answer is that the user cannot log in, but their existing records and history are preserved.
- Updates and Upgrades: Questions about the upgrade process. They will test that you must first upgrade a sub-production instance, then production. They might present a trap where they suggest upgrading production directly.

Common traps and patterns:

- 'Change a property directly in the database' is always wrong. You must use the 'sys_properties' table via the UI or the 'System Properties' module.
- 'Restart the instance' is rarely the first step. The correct first step is usually to check logs.
- 'Delete the record and re-create it' is not the answer for data issues. The correct answer is typically to update the record or check the form configuration.
- 'Assign the admin role to every user' is a trap. The correct approach is to use role-based access control (RBAC), not to assign admin to everyone.
- 'Use the 'Clone' function to move data from production to sub-production' — they might ask the correct direction. Cloning is always from production to sub-production, never the reverse.

Key definitions to memorise:

- Instance: A single deployment of ServiceNow in the cloud.
- Plugin: An optional feature that must be activated.
- Scheduled Job: A script or action that runs on a schedule.
- System Log: The record of platform events.
- Sub-production instance: A non-production environment used for testing.
- Cloning: The process of copying one instance to another.

Exam questions often appear as: 'An administrator is troubleshooting a performance issue. Which of the following tools should they use to view current database activity?' Answer: 'Diagnostics > Database Activity'. Another common ask: 'A user cannot log in. Which of the following is the most likely cause?' Answer: 'The user's account is deactivated or has expired.'

## Step by step

1. **Identify the symptom and scope** — When a problem is reported, first determine what exactly is happening (e.g., blank page, slow load, error message) and who is affected (one user, all users, specific department). This narrows down the possible causes. For example, if only one user is affected, the problem is likely their account or permissions, not the entire instance.
2. **Check the System Logs** — Navigate to 'System Logs > Errors' and filter by the time the problem started. Look for error messages that match the symptom. If no errors appear, check the 'System Log > All' for warnings or informational messages. Logs often contain the exact field or script that failed.
3. **Reproduce the issue in a sub-production instance** — Before making any changes to production, use a clone or sub-production instance to recreate the problem. This ensures you do not accidentally make things worse. If you can reproduce it, you can test your fix safely without impacting real users.
4. **Isolate the root cause** — Using the log data and your reproduction, determine the specific cause: a deleted field, a misconfigured role, a deactivated plugin, or a failed scheduled job. Use tools like 'Audit History' to see who changed what and when. For user issues, check the user's roles and whether their account is active.
5. **Apply the fix and verify** — Implement the fix in the sub-production instance first (e.g., re-create a field, activate a plugin, adjust a role). Test that the problem is resolved. Then apply the same fix to the production instance and verify again. Notify stakeholders that the issue is resolved and document the change.

## Comparisons

### Plugin Activation vs Application Installation

**Plugin Activation:**
- Turns on an existing feature already present in the instance code
- Does not add new tables or modules outside the activated plugin
- Requires only a few minutes and does not import new code

**Application Installation:**
- Imports new code, tables, and modules from the ServiceNow Store
- Often adds multiple plugins and dependencies
- Takes longer and may require post-installation configuration

### Clone vs Backup

**Clone:**
- Creates a full copy of an instance for testing or development
- Overwrites the target instance completely
- Can be performed on demand by administrators

**Backup:**
- Creates a point-in-time snapshot for disaster recovery
- Is automatically taken daily by ServiceNow
- Cannot be initiated by administrators; only ServiceNow can perform restores

### Deactivate User vs Delete User

**Deactivate User:**
- Prevents login but preserves all user records
- Is reversible; reactivation is possible
- Does not remove the user's sys_id or associated data

**Delete User:**
- Permanently removes the user account
- Is irreversible
- May leave orphaned records if not handled carefully

### System Log vs Audit History

**System Log:**
- Records platform events: errors, warnings, info
- Used for troubleshooting real-time problems
- Contents are auto-generated by the platform

**Audit History:**
- Records changes to individual records: who changed what when
- Used for tracking configuration changes
- Requires the 'Audit' plugin to be activated

## Diagram

_A decision flow for troubleshooting a ServiceNow instance problem, starting from symptom identification to applying and verifying a fix._

```mermaid
flowchart TD
    A[Problem Reported] --> B{Check Scope}
    B --> C[Single User]
    B --> D[All Users]
    C --> E[Check User Account Status]
    C --> F[Check User Roles]
    D --> G[Check System Logs]
    G --> H[Error Found?]
    H -- Yes --> I[Isolate Root Cause]
    H -- No --> J[Check Scheduled Jobs]
    I --> K[Test Fix in Sub-Prod]
    J --> K
    K --> L[Apply Fix to Production]
    L --> M[Verify & Notify]
```

## Common misconceptions

- **Misconception:** I can fix any problem by restarting the instance. **Reality:** Restarting the instance is rarely the first or correct step. Most problems are configuration issues that must be fixed by checking logs and settings, not by rebooting. (People are used to fixing home computers by rebooting, but a cloud-based instance rarely benefits from a restart, and it disrupts all users.)
- **Misconception:** If I delete a user, all their records and history are also deleted. **Reality:** Deactivating a user only prevents login. Their created records, comments, and history remain in the database. Deleting a user permanently removes the account but does not necessarily remove associated records (depends on database relationships). (People assume 'delete' means a clean wipe, but ServiceNow preserves data integrity by keeping records linked to the user via a sys_id, even if the user account is gone.)
- **Misconception:** The System Logs only show errors, so if there are no errors, there is no problem. **Reality:** System Logs show errors, warnings, and informational messages. A problem might show as a warning or even a success message that reveals misbehaviour (e.g., a scheduled job running successfully but with wrong parameters). (People think of logs as a 'red light' indicator, but troubleshooting requires reading the full context, not just error levels.)
- **Misconception:** You can change any system setting directly in the database using SQL. **Reality:** ServiceNow does not allow direct database access. All configuration changes must be made through the UI or via REST APIs. Modifying the database directly can break the instance permanently. (Beginners who have used other databases assume they can use SQL commands, but ServiceNow abstracts the database entirely for security and stability.)
- **Misconception:** A 'clone' is the same as a 'backup'. **Reality:** A clone is a copy of an entire instance (including all data and configuration) used for testing or development. A backup is a point-in-time snapshot that can be restored if the instance fails. Clones are not restorable in the same way. (The two terms are often used interchangeably in casual conversation, but ServiceNow distinguishes them by purpose and functionality.)

## Key takeaways

- The first step in troubleshooting is always to check the System Logs, specifically the Error Log, to see what the platform recorded about the problem.
- A user who is deactivated cannot log in, but their existing records and history remain visible and intact in the system.
- Plugins must be activated in the application navigator before their features become available; activation does not require restarting the instance.
- When upgrading, always apply the upgrade to a sub-production instance first, test it, then apply to production.
- The 'glide.ui.session_timeout' property controls how long a user can stay logged in without activity before being automatically logged out.
- Changing a system property via the database is never the correct answer — always use the 'System Properties' module in the UI.

## FAQ

**Why can't I delete a field from a table?**

ServiceNow prevents you from deleting a field if it is currently referenced in a form, a script, or a report. You must first remove all references to the field before you can delete it. This protects data integrity.

**What does 'instance is in maintenance mode' mean?**

Maintenance mode is a setting that displays a message to all users that the instance is unavailable. Only administrators can log in. It is used during upgrades or major troubleshooting to prevent user interference.

**How do I check if a scheduled job ran successfully?**

Go to 'Scheduled Jobs' and open the job record. Click the 'Execution History' related list. It shows each run, its start time, end time, and whether it succeeded or failed. An error message in the 'Output' field indicates the problem.

**What is a sub-production instance and why do I need one?**

A sub-production instance is a non-live copy of your instance used for testing changes, upgrades, and troubleshooting. You need one because you should never make changes directly in production without testing first, as mistakes could affect all users.

**Why can't I see the 'Knowledge' module in my application navigator?**

The Knowledge Management plugin is not activated. Go to 'System Applications > All Applications', find the 'Knowledge Management' plugin, and click 'Activate'. It may take a few minutes to appear.

**What happens if I change a system property incorrectly?**

If you change a property to an invalid value (e.g., a text value where a number is expected), the instance might behave unexpectedly or break. Always make a note of the original value before changing, and test in a sub-production instance first.

## Check your understanding

1. **A user reports they cannot log in to the instance. What is the first thing you should check?**

   Answer: Check whether the user's account is active and not expired. Navigate to 'User Administration' and view the user record.

2. **Which log would you check to see all error messages generated by the platform in the last hour?**

   Answer: Check the 'System Logs > Errors' log. Filter by time range 'Last hour' to see relevant entries.

3. **What is the difference between a clone and a backup?**

   Answer: A clone is a full instance copy used for testing, while a backup is a point-in-time snapshot used for disaster recovery. Clones can be initiated by administrators, but backups are automatic and restorable only by ServiceNow.

4. **You need to activate the 'Knowledge Management' feature. What is the correct procedure?**

   Answer: Navigate to 'System Applications > All Applications', find 'Knowledge Management', and click 'Activate'. The feature will appear in the navigation after a few minutes.

5. **A scheduled job failed to run. Where do you find information about why it failed?**

   Answer: Open the scheduled job record and click the 'Execution History' related list. The output column will show any error messages or failure reasons.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/servicenow-csa/instance-administration-and-troubleshooting