Introduction

ServiceNow incident states define where an incident currently stands in its lifecycle, from the moment a user reports an issue until the issue is resolved and formally closed. In a real ServiceNow implementation, incident state is much more than a status field. It influences how service desk teams work on tickets, when SLAs continue to run, when users receive notifications, whether additional information is required, and when an incident can move toward closure.

For example, consider an employee who cannot access the corporate VPN. The service desk creates an incident, assigns it to the network team, investigates the connectivity problem, waits for the employee to provide additional information, resolves the issue, and eventually closes the record. Each stage can be represented by a different incident state.

ServiceNow’s documented incident lifecycle includes states such as New, In Progress, On Hold, Resolved, Closed, and Canceled. The exact behavior can vary depending on the application’s configuration, release, plugins, and customizations.

Understanding these states is important for ServiceNow administrators, developers, ITSM consultants, service desk analysts, and anyone working with Incident Management integrations.

What Are ServiceNow Incident States?

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

A typical lifecycle looks like:

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

There can also be alternate paths such as cancellation or reopening.

ServiceNow’s published incident lifecycle documentation shows New, In Progress, On Hold, Resolved, Closed, and Canceled as lifecycle states.

One important implementation point is that Resolved and Closed are not necessarily the same thing.

A resolved incident may still require user confirmation, a closure period, or automated closure processing before it becomes Closed.

Why Incident States Matter in Real Projects

During implementation projects, it is common for customers to initially treat State as a simple dropdown.

That approach creates problems later.

Incident State can participate in:

• SLA calculations
• Notifications
• Assignment workflows
• Escalation rules
• Business rules
• Flow Designer flows
• Reporting
• Dashboards
• Integration logic
• Automation
• User communications
• Closure policies

For example, a company may define:

“When an incident is On Hold awaiting customer information, pause the response SLA.”

That requirement is not simply a form configuration. The implementation team must determine exactly which state and hold reason represent that condition and how the SLA definition should behave.

Similarly:

“When an incident moves to Resolved, send the requester the resolution details.”

This introduces a dependency between state transition, notification, resolution information, and possibly automatic closure.

Key ServiceNow Incident States Explained

1. New

New normally means the incident has been created but has not yet entered active investigation.

Example:

An employee reports:

“I cannot connect to the corporate VPN.”

The service desk creates:

• Incident number: INC0012345
• Caller: John Smith
• Category: Network
• Subcategory: VPN
• Impact: 2
• Urgency: 2
• Assignment group: Network Support
• State: New

The incident is now waiting for triage or assignment activity.

Consultant Tip

Do not automatically assume that every newly created incident should remain in New.

Some organizations configure assignment or automation that moves an incident into active work immediately. Therefore, always validate the actual state transition behavior in the target instance rather than relying only on textbook lifecycle diagrams.

2. In Progress

In Progress indicates that the support team is actively working on the incident.

For example:

1. Network Support receives the VPN incident.
2. An analyst opens the incident.
3. The analyst checks the user’s account.
4. VPN authentication logs are reviewed.
5. The analyst tests the user’s access.
6. The incident is moved to In Progress.

At this stage, the incident represents active operational work.

Typical activities include:

• Troubleshooting
• Log analysis
• Configuration verification
• User communication
• Infrastructure checks
• Testing
• Coordination with another technical team

3. On Hold

On Hold means work cannot currently continue because the incident depends on something outside the immediate support activity.

ServiceNow implementations commonly use hold reasons to explain why the incident is paused.

Examples include:

• Awaiting Caller
• Awaiting Vendor
• Awaiting Change
• Awaiting Problem investigation
• Awaiting additional information

The exact choices depend on the ServiceNow version and implementation.

A practical example:

A database incident requires a storage vendor to provide diagnostic information.

The analyst may set:

State: On Hold
Reason: Awaiting Vendor

The incident is not forgotten. It is explicitly indicating why progress is temporarily paused.

ServiceNow Community documentation also describes On Hold as a state where responsibility temporarily shifts while information, evidence, or a resolution is obtained.

4. Resolved

Resolved indicates that the support team believes the underlying incident has been fixed.

For example:

The VPN issue was caused by an expired authentication certificate.

The administrator renews the certificate and verifies that the employee can connect.

The analyst records:

• Resolution code
• Resolution notes
• Resolution details
• Resolution time

The incident is then moved to Resolved.

A critical implementation distinction is:

Resolved does not always mean the incident is permanently closed.

Organizations may use a defined closure period during which the requester can indicate that the issue still exists.

ServiceNow’s incident documentation describes reopening behavior from Resolved back to active work when a user is not satisfied with the resolution.

5. Closed

Closed represents the completed end of the normal incident lifecycle.

Depending on implementation, closure may occur:

• Automatically after a defined period
• Through an agent action
• Through a scheduled process
• After requester confirmation
• Through a workflow or Flow Designer process

The important point is that Resolved and Closed should have clearly defined business meanings.

A common implementation pattern is:

Resolved → waiting period → Closed

This provides a controlled window for reopening.

6. Canceled

Canceled is used when an incident should no longer continue through the normal resolution process.

Example:

A duplicate incident was created for an issue already being handled under INC0012345.

The duplicate record can be canceled rather than artificially resolving it.

Another example is when an incident was created by mistake.

Cancellation should have a clear operational definition because reporting teams may want to distinguish:

• Successfully resolved incidents
• Canceled incidents
• Duplicate incidents
• Invalid incidents

ServiceNow Incident State Lifecycle

A simplified lifecycle can be represented as:

              ┌──────────────┐
              │     New      │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │ In Progress  │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │   On Hold    │
              └──────┬───────┘
                     │
                     ↓
              ┌──────────────┐
              │ In Progress  │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │   Resolved   │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │    Closed    │
              └──────────────┘

The actual transition model can include additional routes depending on configuration.

For example, a resolved incident may be reopened and returned to active work.

Real-World Implementation Scenarios

Scenario 1: Incident Waiting for Customer Information

A payroll application user reports:

“My payroll statement is incorrect.”

The support analyst needs the employee’s previous payslip and additional details.

The incident moves:

New → In Progress → On Hold

Hold reason:

Awaiting Caller

The employee provides the required information.

The incident moves back to:

In Progress

The analyst investigates and resolves the issue.

Finally:

Resolved → Closed

Implementation Consideration

The organization should define whether SLA timers continue or pause during the On Hold period. This must be validated against the organization’s contractual SLA requirements rather than assuming that On Hold automatically pauses every SLA.

Scenario 2: Infrastructure Incident Requiring a Change

A production server has insufficient capacity.

The incident cannot be permanently resolved until a change request is implemented.

The flow could be:

New → In Progress → On Hold

Hold reason:

Awaiting Change

The change team implements the approved change.

The incident returns to:

In Progress

The support team validates the server.

If the issue is fixed:

Resolved → Closed

This is a common example of why incident state and related ITSM processes must be designed together.

Scenario 3: Third-Party Vendor Dependency

A payment integration is failing because an external banking provider is returning an unexpected response.

The service desk assigns the incident to the integration support team.

The team confirms that the problem is external and raises a vendor ticket.

The incident becomes:

On Hold → Awaiting Vendor

After the vendor provides the fix:

In Progress

The integration team tests the transaction.

The incident is then:

Resolved → Closed

In an enterprise environment, this state history is valuable during SLA reviews because it explains why technical resolution took longer.

Incident States and Automation

Incident state becomes especially important when implementing automation.

For example, a business requirement might be:

“When an incident is resolved, notify the caller and automatically close it after five days unless the user reopens it.”

A high-level automation might be:

Incident State = Resolved
        ↓
Send resolution notification
        ↓
Wait for configured period
        ↓
Check current state
        ↓
If still Resolved
        ↓
Close Incident

If the user reopens the incident during the waiting period:

Resolved
   ↓
User reports issue continues
   ↓
In Progress
   ↓
Investigation

This is why developers should not build automation solely around assumptions about numeric state values.

Incident State and Integrations

Incident state is also important when integrating ServiceNow with external systems.

Consider an enterprise architecture:

Monitoring Tool
      ↓
ServiceNow Incident
      ↓
Assignment
      ↓
Investigation
      ↓
Resolution
      ↓
Closed
      ↓
External Reporting System

An integration may need to synchronize incident state with another platform.

For example:

Important Developer Consideration

Do not assume that the numeric representation of a ServiceNow state is universally safe to hard-code across implementations.

Community examples show that numeric state values and state-related behavior can be affected by configuration and historical version differences.

For integration development, validate the target instance’s dictionary/configuration and API behavior.

Frequently Asked Interview Questions

1. What are incident states in ServiceNow?

Incident states represent the current stage of an incident lifecycle. Common states include New, In Progress, On Hold, Resolved, Closed, and Canceled.

2. What is the difference between New and In Progress?

New generally means the incident has been logged but active investigation has not started. In Progress indicates that the support team is actively working on the incident.

3. Why is On Hold used?

On Hold is used when work cannot continue temporarily because the incident depends on another party, information, a vendor, a change, or another process.

4. What is the difference between Resolved and Closed?

Resolved generally means the support team has addressed the issue. Closed represents completion of the incident lifecycle according to the organization’s closure process.

5. Can a resolved incident be reopened?

Yes. Depending on the implementation and applicable rules, a resolved incident can be reopened when the issue persists or the requester rejects the resolution. ServiceNow documentation describes a transition from Resolved back to In Progress for reopening scenarios.

6. What happens when an incident is placed On Hold?

The incident indicates that active work is temporarily paused. The specific behavior of SLAs, notifications, and automation depends on configuration.

7. Can an incident be canceled?

Yes. Canceled can be used when the incident should not continue through the normal resolution lifecycle, such as when a record is created incorrectly or is identified as unnecessary.

8. Why should On Hold reasons be configured?

Hold reasons provide operational context. Instead of simply saying that work stopped, the organization can identify whether it is waiting for the caller, vendor, change, or another dependency.

9. Does On Hold automatically stop an SLA?

Not necessarily. SLA behavior depends on the SLA definition and its conditions. This should be tested explicitly during implementation.

10. Should developers hard-code state numbers?

It is safer to validate state values and behavior in the target instance rather than blindly assuming numeric values from another ServiceNow environment.

11. What happens after an incident is resolved?

The incident may remain Resolved for a defined period before it is automatically or manually Closed, depending on organizational configuration.

12. How can incident state be used in Flow Designer?

State can be used as a condition or trigger for automation, such as sending notifications when an incident is resolved or initiating a follow-up process.

13. Why is state important for reporting?

State allows organizations to measure the incident pipeline, active workload, resolution volumes, aging, closure patterns, and operational performance.

14. What is a practical example of On Hold?

If a support team needs information from a third-party vendor before continuing troubleshooting, the incident can be placed On Hold with an appropriate vendor-related reason.

15. Why should incident lifecycle transitions be tested?

Because state changes can affect SLAs, mandatory fields, notifications, business rules, integrations, and reporting. A seemingly simple state customization can therefore affect several downstream processes.

Common Implementation Challenges

Incorrect State Transitions

A customer may want:

New → Resolved

without allowing analysts to work through In Progress.

Such requirements should be evaluated carefully because bypassing lifecycle states can affect reporting and operational controls.

Confusing Resolved With Closed

If users treat Resolved and Closed as identical, the organization may lose the ability to distinguish technical resolution from formal completion.

Poor On Hold Governance

Allowing analysts to place incidents On Hold without meaningful reasons makes operational reporting difficult.

Hard-Coded State Numbers

Integration developers sometimes copy numeric values from another instance.

This can create compatibility problems when the target environment has different configuration or customized state behavior.

Automation Loops

A poorly designed flow can produce behavior such as:

Resolved
   ↓
Automation updates record
   ↓
Business Rule executes
   ↓
State changes
   ↓
Automation executes again

State-based automation should therefore be tested for recursion and unintended transitions.

Best Practices for ServiceNow Incident States

1. Define Each State Operationally

Create a simple lifecycle document explaining:

• When the state is used
• Who can select it
• What information is mandatory
• What state comes next
• What automation occurs

2. Define On Hold Reasons Carefully

Avoid creating dozens of nearly identical hold reasons.

Use reasons that support operational reporting.

3. Separate Resolved From Closed

Define what each state means from a business-process perspective.

4. Test SLA Behavior

Create test incidents for:

• New
• In Progress
• On Hold
• Resolved
• Closed

Then verify SLA timers and pause conditions.

5. Test Reopening

A complete UAT scenario should include:

Incident → Resolved
          ↓
User rejects resolution
          ↓
Incident reopened
          ↓
In Progress
          ↓
Resolution

6. Validate Integrations

If an external application consumes incident state, test every state that the integration supports.

7. Avoid Unnecessary Custom States

Before creating a custom incident state, check whether an existing state plus a meaningful sub-status, reason, category, or related record can satisfy the requirement.

8. Build Reports Around Business Meaning

Instead of simply reporting “number of incidents by state,” create meaningful operational metrics such as:

• Open incidents by assignment group
• Incidents On Hold by reason
• Resolved incidents awaiting closure
• Aging incidents
• Reopened incidents
• Canceled incidents
• Incidents exceeding SLA

Practical Consultant Checklist

Before moving an Incident Management implementation to production, verify:

• State definitions are documented.
• State transitions are approved.
• On Hold reasons are defined.
• Mandatory fields for Resolved are tested.
• Closure behavior is tested.
• Reopening behavior is tested.
• SLA behavior is validated.
• Notifications are tested.
• Flow Designer automation is tested.
• Business Rules are reviewed.
• Integration mappings are validated.
• Reports correctly interpret each state.
• Duplicate and canceled incident handling is documented.
• UAT includes negative scenarios.

Frequently Asked Questions

What is the normal ServiceNow incident lifecycle?

A common lifecycle is New → In Progress → On Hold/Resolution activities → Resolved → Closed, with alternative paths such as cancellation and reopening depending on configuration.

Does Resolved mean the incident is permanently finished?

Not necessarily. Resolved generally indicates that the support team believes the issue has been fixed. The organization may keep the incident in Resolved before moving it to Closed, and reopening may be possible during that period.

Can incident states be customized?

ServiceNow implementations can customize lifecycle behavior, but state changes should be evaluated carefully because they can affect business rules, SLAs, notifications, reporting, and integrations.

Summary

ServiceNow incident states provide the operational framework for managing an incident from creation through completion. The important point for an implementation consultant is to understand that State is not simply a field displayed on the Incident form.

A state transition can affect the entire incident-management process.

For example:

New tells the service desk that the incident needs attention.

In Progress indicates active investigation.

On Hold explains that progress depends on another condition or party.

Resolved indicates that the support team believes the issue has been fixed.

Closed represents completion of the incident lifecycle.

Canceled handles incidents that should not continue through normal resolution.

In a real implementation, the most important work is not merely configuring these choices. The consultant must determine how states interact with SLAs, notifications, automation, assignment, integrations, reporting, and user communication.

That lifecycle should be documented, configured, tested through realistic scenarios, and validated during UAT before production deployment.

For additional Oracle Cloud reference material and the latest 26A documentation, refer to the Oracle Cloud SaaS documentation and the Oracle Fusion Cloud Time and Labor 26A What’s New guide. The Time and Labor implementation documentation explains the rule-based processing model, setup tasks, validations, calculations, and downstream time processing.