Introduction

Incident states in ServiceNow define the current stage of an incident throughout its lifecycle, from initial creation and investigation to resolution and closure. For an implementation team, understanding these states is important because incident state values control how support teams work on tickets, when SLAs are evaluated, what users see, and when an incident can move toward closure.

In a real ServiceNow implementation, incident states should not be treated simply as status labels. They form part of the operational process. For example, an incident assigned to the Service Desk may move from New to In Progress, then to On Hold while waiting for information, and finally to Resolved after the technical team fixes the issue.

A well-designed state model helps organizations maintain consistent ticket handling, reporting, SLA measurement, escalation, and auditability.

What Are Incident States in ServiceNow?

An incident state represents the current processing stage of an incident record.

In the standard ServiceNow Incident Management process, commonly used states include:

The exact available values and behavior can vary depending on the ServiceNow release, application configuration, plugins, customizations, and organization-specific workflows.

This distinction is important during implementation. Consultants should always verify the actual state choices and transitions in the target ServiceNow instance instead of assuming that every customer instance uses exactly the same configuration.

Why Incident States Matter in ServiceNow

An incident lifecycle usually involves multiple teams.

For example:

Employee → Service Desk → Application Support → Infrastructure Team → Service Desk → Employee

Without clearly defined states, support teams may not know whether an incident is actively being investigated, waiting for information, or ready for closure.

Incident states support several operational activities:

• Incident lifecycle management
• SLA processing
• Assignment and escalation
• Service Desk productivity
• Incident reporting
• Queue management
• Automation
• Notifications
• Audit tracking
• Resolution and closure controls

Example

Consider an employee who cannot access an Oracle Fusion application.

The Service Desk creates an incident:

“User unable to log in to Oracle Fusion.”

Initially:

New

The Service Desk starts investigation:

In Progress

The Service Desk discovers that the user account is locked and raises a request with the identity team:

On Hold

The identity team unlocks the account:

In Progress

The Service Desk confirms successful login with the employee:

Resolved

After the required closure process:

Closed

This sequence gives management a clear history of what happened.

Common Incident States and Their Meaning

New

The New state normally represents an incident that has been created but has not yet entered active investigation.

Typical examples include:

• User submits an incident through the Service Portal.
• Monitoring tool creates an incident automatically.
• Service Desk agent creates an incident manually.
• Integration creates an incident through an API.

Consultant Tip

Do not automatically interpret every newly created ticket as “unassigned.”

A ticket can technically be in New while already having:

• Assignment group
• Assigned to
• Priority
• Category
• Configuration item

State and assignment are separate concepts.

In Progress

In Progress indicates that work is actively being performed.

The assigned technician may be:

• Reproducing the problem
• Checking logs
• Reviewing configuration
• Contacting another team
• Testing a workaround
• Investigating infrastructure
• Checking integrations
• Reviewing recent changes

For example, suppose an Oracle Fusion integration incident reports:

“Employee data is not reaching the downstream payroll system.”

The support engineer may inspect:

1. Integration execution status.
2. OIC monitoring.
3. Authentication.
4. REST/SOAP response.
5. Transformation errors.
6. Target-system response.

The incident remains In Progress while this investigation is actively happening.

On Hold

On Hold is one of the most important states from an operational perspective.

An incident may be placed on hold when the support team cannot continue immediately because it is waiting for something.

Common reasons include:

• Awaiting user information
• Awaiting vendor response
• Awaiting approval
• Awaiting another team
• Awaiting scheduled maintenance
• Awaiting infrastructure change
• Awaiting customer confirmation

Example

A user reports:

“The invoice approval page is displaying an error.”

The application support team requires a screenshot and transaction number.

The analyst requests the information from the user and places the incident on hold.

The reason should be captured clearly.

Why the On Hold Reason Matters

If every team simply selects “On Hold,” management cannot distinguish between:

• Waiting for customer
• Waiting for vendor
• Waiting for another internal team
• Waiting for a scheduled activity

For reporting and SLA analysis, the hold reason can be just as important as the state itself.

Resolved

Resolved generally indicates that the technical team believes the incident has been fixed or an acceptable workaround has been provided.

A good resolution should contain enough information for another support analyst to understand what happened.

For example:

Root cause: User account was locked after multiple authentication failures.
Action: Identity team unlocked the account and reset the authentication policy.
Validation: User successfully logged in and confirmed application access.

This is much more useful than:

Issue fixed.

Resolution Is Not the Same as Closure

This distinction is frequently misunderstood.

Resolved means the support team has completed its technical work.

Closed means the incident lifecycle has been completed according to the organization’s closure rules.

This separation provides an opportunity for:

• User confirmation
• Automated closure
• Closure validation
• Quality checks
• Reporting

Closed

The Closed state represents a completed incident.

Organizations may configure specific conditions before an incident can be closed.

For example:

• Incident must first be Resolved.
• Resolution code must be populated.
• Resolution notes must be populated.
• Required fields must be completed.
• A configured waiting period may have elapsed.
• User confirmation may be required.

The exact closure behavior depends on the implementation.

Canceled

A canceled incident is one that should no longer proceed through the normal incident lifecycle.

Examples include:

• Duplicate incident
• Incorrectly submitted ticket
• Test ticket
• Invalid incident
• Request submitted as an incident
• Monitoring false positive

Example

A monitoring integration creates three incidents for the same infrastructure event.

The support team keeps one valid incident and cancels the duplicates.

This prevents unnecessary work and improves reporting quality.

Incident State Flow

A typical lifecycle can be represented as:

New → In Progress → On Hold → In Progress → Resolved → Closed

Other transitions may also occur depending on business rules.

For example:

New → Canceled

or:

In Progress → Resolved

or:

Resolved → In Progress

The last transition can be useful when a user reports that the problem has returned after resolution.

However, reopening behavior should be deliberately designed rather than left to individual agents.

Real-World Incident State Scenarios

Scenario 1: Oracle Fusion Login Issue

A finance user cannot access Oracle Fusion.

Lifecycle

New

The incident is created through the Service Portal.

In Progress

Service Desk verifies the user’s identity and checks account status.

On Hold

The incident is waiting for the identity management team.

In Progress

Identity team confirms the account was unlocked.

Resolved

User confirms that login works.

Closed

Incident satisfies the organization’s closure rules.

Implementation Lesson

The state history provides a useful operational timeline and helps management understand where delays occurred.

Scenario 2: Integration Failure

An organization uses Oracle Integration Cloud to send customer information from one application to another.

An automated monitoring process detects failures.

The integration creates an incident:

“Customer synchronization failed.”

The support analyst starts investigation.

New → In Progress

The analyst discovers that the target API is unavailable.

In Progress → On Hold

The infrastructure team is working on the target environment.

After the API becomes available:

On Hold → In Progress

The analyst reruns or validates the integration.

After successful processing:

In Progress → Resolved

The incident eventually becomes:

Closed

Consultant Observation

In integration-heavy environments, incident states can provide valuable operational information when combined with:

• Integration logs
• Error codes
• Assignment groups
• Configuration items
• Priority
• SLA data

Scenario 3: Hardware Replacement

An employee reports a laptop failure.

The Service Desk performs initial diagnosis.

New → In Progress

The technician determines that the device requires hardware replacement.

In Progress → On Hold

The replacement device is being shipped.

Once the device arrives:

On Hold → In Progress

The technician configures the device.

The employee confirms successful operation:

Resolved

After closure conditions are satisfied:

Closed

The organization can later analyze how much time incidents spend in each state.

How Incident State Configuration Works

Incident states are normally associated with the Incident table and its lifecycle configuration.

A consultant should investigate three areas:

1. State values
2. Allowed state transitions
3. Business behavior associated with each state

A state value by itself does not create a complete process.

For example:

State = On Hold

does not automatically explain:

• Why the incident is on hold.
• Whether SLA timers should behave differently.
• Whether notifications should be triggered.
• Whether assignment should change.
• Whether the user should be notified.
• Whether the incident can be resolved directly.

Those behaviors are normally implemented through configuration, business rules, flows, workflows, SLAs, UI policies, data policies, or other platform capabilities depending on the ServiceNow implementation.

Step-by-Step: Reviewing Incident States

Because ServiceNow instances can be customized, administrators should first inspect the organization’s actual configuration.

Step 1 – Open an Incident

Navigate to the Incident application and open an existing incident.

Review the State field.

Check which values are available.

Do not assume that the customer’s instance contains only the standard values.

Step 2 – Review State Transitions

Select different states and observe how the form behaves.

For example:

• Can New move directly to Resolved?
• Can On Hold move to Resolved?
• Can Closed incidents be reopened?
• Does changing State require additional fields?
• Does selecting On Hold require a hold reason?

These questions reveal whether lifecycle controls have been implemented.

Step 3 – Review Mandatory Fields

Check what becomes mandatory for different states.

For example, when selecting Resolved, the implementation may require:

• Resolution code
• Resolution notes

When selecting On Hold, the implementation may require:

• Hold reason

These controls improve data quality.

Step 4 – Test Notifications

Change an incident state in a non-production environment.

Verify whether notifications are triggered.

Examples:

• Incident assigned
• Incident placed on hold
• Incident resolved
• Incident closed
• Incident reopened

Document the expected behavior before promoting configuration.

Testing Incident States

A practical test case should validate both the state and the related business behavior.

Test Case

Create an incident:

Short description:
“Unable to access Oracle Fusion”

Assignment group:
Application Support

Priority:
Based on the organization’s impact and urgency rules.

Test 1 – New

Expected:

• Incident is created.
• State is New.
• Assignment information is correct.

Test 2 – In Progress

Change state to In Progress.

Expected:

• State changes successfully.
• Required validations execute.
• Relevant automation behaves as designed.

Test 3 – On Hold

Select On Hold.

Expected:

• Hold reason becomes mandatory if configured.
• SLA behavior matches the agreed design.
• Appropriate notification is generated if configured.

Test 4 – Resolved

Provide:

• Resolution code
• Resolution notes

Expected:

• Incident becomes Resolved.
• Resolution information is saved.

Test 5 – Closed

Attempt to close the incident.

Expected:

• Closure rules are enforced.
• Required fields remain complete.
• Incident is moved to Closed.

Incident States and SLA Management

Incident states can have an important relationship with SLA calculations.

However, consultants should avoid assuming that changing the incident state automatically stops an SLA.

SLA behavior is controlled by the SLA definition and its conditions.

For example, an organization may define a resolution SLA with conditions such as:

Start: Incident created

Pause: Incident is On Hold for an approved reason

Stop: Incident is Resolved or Closed

The actual implementation should be validated against the organization’s SLA requirements.

Example

Suppose a Priority 1 incident has a four-hour resolution target.

If the incident is waiting for a customer response, the organization may have a policy that allows the SLA clock to pause.

That behavior must be deliberately configured and tested.

Common Implementation Challenges

1. Too Many Custom States

Some organizations create excessive custom states to represent every possible operational situation.

This can create:

• Complex reporting
• Difficult workflows
• Confusing dashboards
• More testing effort
• Difficult integrations

Use states for meaningful lifecycle stages, not every minor activity.

2. Confusing State with Assignment

An incident being assigned to the Network Team does not mean it is “In Progress.”

Assignment answers:

Who owns the work?

State answers:

Where is the incident in its lifecycle?

These are different dimensions.

3. Poor On Hold Usage

Agents sometimes use On Hold as a general-purpose state.

For example:

“I haven’t started this ticket yet, so I put it On Hold.”

That creates inaccurate operational data.

On Hold should represent a genuine waiting condition defined by the organization’s process.

4. Weak Resolution Notes

Poor resolution notes reduce the value of incident history.

Instead of:

“Fixed.”

capture:

• Problem
• Diagnosis
• Action taken
• Validation
• Workaround, if applicable

5. Reopening Logic Is Not Defined

Organizations should decide what happens when a user reports that a resolved incident has returned.

Possible designs include:

• Reopen the same incident.
• Create a new incident.
• Automatically reopen within a defined period.
• Create a related incident.

The correct approach depends on operational requirements.

Best Practices for Incident State Management

Keep the State Model Simple

Use a small number of meaningful lifecycle stages.

Avoid creating states such as:

• Investigating
• Troubleshooting
• Waiting
• Testing
• Validating
• Pending Approval

unless there is a clear operational reason for each.

Some of these activities can be represented through other fields.

Define State Transition Rules

Document:

This becomes a useful reference for developers, testers, Service Desk teams, and process owners.

Make Resolution Data Mandatory

When moving to Resolved, capture meaningful information.

At minimum:

• Resolution code
• Resolution notes

For major incidents, organizations may also capture:

• Root cause
• Workaround
• Permanent fix
• Related problem record
• Change record

Align State Behavior With SLA Design

Before implementing SLA pause conditions, document exactly which states should pause or stop the SLA.

Do not configure SLA logic based purely on assumptions about state names.

Use Reports to Identify State Bottlenecks

A useful operational report can show:

If On Hold consumes most of the incident lifecycle, management can investigate whether the issue is related to:

• Vendor dependencies
• Approval delays
• Poor ticket information
• Cross-team handoffs
• Resource availability

The state history becomes an operational improvement tool rather than just a ticket field.

Incident States vs Incident Lifecycle

These terms are related but should not be treated as identical.

Incident lifecycle describes the complete process from creation through closure.

Incident state identifies the current point within that lifecycle.

For example:

Incident lifecycle: Identification → Investigation → Resolution → Closure

while the actual ServiceNow states may be:

New → In Progress → On Hold → Resolved → Closed

The lifecycle is the process model; states are the operational representation of that process in the platform.

3 Frequently Asked Questions

1. What is the difference between Resolved and Closed in ServiceNow?

Resolved normally indicates that the technical team has completed the work and documented the solution. Closed represents completion of the incident lifecycle according to the organization’s closure rules.

The exact transition and timing should be verified in the configured ServiceNow instance.

2. Does On Hold automatically pause an SLA?

Not necessarily. SLA behavior depends on the conditions configured in the applicable SLA definition. An organization can configure particular incident states or conditions to pause SLA calculations.

Always test the actual SLA definition rather than assuming that On Hold automatically pauses every SLA.

3. Can a Resolved incident be reopened?

It can be possible depending on the organization’s configuration. Some implementations allow a resolved incident to return to an active state when the issue reoccurs or the user rejects the resolution.

The exact reopening rules should be documented as part of the incident management design.

Summary

Incident states in ServiceNow provide the operational structure for managing incidents from creation through resolution and closure. States such as New, In Progress, On Hold, Resolved, Closed, and Canceled help support teams communicate the current lifecycle position of an incident.

For a real implementation, the important work is not simply knowing the state names. Consultants need to understand how states interact with:

• Assignment groups
• SLAs
• Notifications
• Mandatory fields
• Automation
• Resolution codes
• Closure rules
• Reporting
• Integrations
• Reopening logic

A practical incident design should keep the state model understandable, define valid transitions, capture meaningful resolution information, and align state behavior with the organization’s SLA and support processes.

For additional reference, review the official Oracle Cloud SaaS documentation when the incident process involves Oracle Fusion applications or integrations. For Oracle Time and Labor specifically, refer to the applicable Oracle Fusion Cloud HCM Time and Labor documentation in the Oracle documentation library and verify the documentation corresponding to the current 26A release.