Types of Tickets In ServiceNow
Introduction
Understanding the types of tickets in ServiceNow is fundamental for anyone working with IT Service Management (ITSM). In a real ServiceNow implementation, every user issue, request, infrastructure change, recurring failure, or operational task should be classified correctly because the ticket type determines the workflow, assignment, SLA treatment, approvals, escalation process, reporting, and closure rules.
A common mistake in new implementations is treating every user interaction as an Incident. For example, “I need a new laptop” is not normally an incident, while “my laptop has stopped working” is an incident. Similarly, repeatedly reported database failures may begin as incidents but eventually require a Problem record to investigate the underlying root cause. A planned production deployment may require a Change Request, while access to an approved application may be fulfilled through a Service Request. ServiceNow provides capabilities for managing these processes together within ITSM.
This article explains the major ServiceNow ticket types, how they differ, how they relate to one another, and how an implementation consultant should decide which record type to use.
What Is a Ticket in ServiceNow?
“Ticket” is commonly used by organizations as a generic term for a record representing work that needs to be tracked.
However, technically, ServiceNow has different record types for different business processes.
For example:
| Business situation | Typical ServiceNow record |
|---|---|
| Employee cannot access email | Incident |
| Repeated application failure requiring root-cause investigation | Problem |
| Deploying a planned application release | Change Request |
| Requesting a new laptop | Service Request |
| Requesting software access | Service Request |
| HR employee question | HR Case |
| Customer support issue | Case |
| Security investigation | Security Incident |
| Infrastructure discovery/configuration activity | CMDB-related records |
The exact applications and record types available depend on the ServiceNow products and applications activated in the instance.
Therefore, when someone asks, “What are the ticket types in ServiceNow?”, the consultant should first clarify whether they mean core ITSM ticket types or every type of record used across the ServiceNow platform.
Core ServiceNow ITSM Ticket Types
For a typical ITSM implementation, four categories are especially important:
- Incident
- Problem
- Change Request
- Service Request
They solve different business problems.
Quick Comparison
| Type | Primary purpose | Example |
|---|---|---|
| Incident | Restore service quickly | VPN is not working |
| Problem | Find and eliminate root cause | VPN repeatedly fails |
| Change | Control planned modification | Upgrade VPN infrastructure |
| Service Request | Fulfill a standard user request | Request VPN access |
The distinction is important because the same business event can sometimes create multiple related records.
For example:
Employee reports VPN failure → Incident → recurring failure identified → Problem → infrastructure fix required → Change
This relationship is one of the most important concepts to understand when working with ServiceNow ITSM.
1. Incident Tickets in ServiceNow
An Incident is generally used when an IT service is interrupted, degraded, or not operating as expected.
The objective of Incident Management is primarily restoring normal service as quickly as possible.
Real-world examples
Consider these situations:
- Employee cannot log into Oracle Fusion.
- Corporate VPN is unavailable.
- Outlook is not synchronizing.
- A production application is throwing errors.
- Printer connected to the corporate network has stopped working.
- A business application has become significantly slower.
These are normally incidents because something that should work is not working correctly.
Example
An employee submits:
“I was able to access the application yesterday, but today I receive an authentication error.”
A service desk agent could create an incident containing:
- Caller
- Short description
- Description
- Category
- Subcategory
- Configuration Item
- Business service
- Impact
- Urgency
- Assignment group
- Work notes
- Additional comments
The incident is then routed to the appropriate support team.
Incident lifecycle
A typical implementation may use a lifecycle similar to:
New → In Progress → On Hold → Resolved → Closed
The exact states and transitions depend on the organization’s configuration and ServiceNow application/version.
Consultant tip
Do not use Incident merely because a user contacts the service desk.
Ask:
“Is an existing service broken or degraded?”
If yes, Incident is usually the appropriate classification.
2. Problem Tickets in ServiceNow
A Problem is used to investigate the underlying cause of one or more incidents.
This distinction is critical.
An incident asks:
“How do we restore service?”
A problem asks:
“Why does this keep happening, and how do we prevent it?”
Real-world example
Suppose 50 employees report that an Oracle-related application becomes unavailable every Monday morning.
The service desk creates incidents and restores service each time.
After analyzing the history, the support team identifies that the application database reaches a resource threshold during a scheduled process.
At this point, simply resolving each incident is not enough.
A Problem record can be created to investigate:
- Root cause
- Frequency
- Business impact
- Related incidents
- Workaround
- Permanent corrective action
ServiceNow supports relationships between incidents, problems, and changes. An incident can, for example, lead to the creation of a Problem or Change.
Typical Problem lifecycle
A problem process may include:
New → Assess → Investigate → Root Cause Identified → Fix Planned → Resolved → Closed
The actual workflow depends on implementation.
Important fields
A Problem record may contain:
- Problem number
- Short description
- Description
- Business service
- Configuration Item
- Assignment group
- Problem coordinator
- Priority
- Root cause
- Workaround
- Related incidents
- Related change request
Consultant tip
Do not automatically create a Problem for every incident.
A Problem is useful when there is a recurring, significant, or structurally important issue requiring root-cause analysis.
3. Change Request Tickets
A Change Request is used when an organization needs to make a controlled modification to an IT environment.
Examples include:
- Deploying an application release
- Updating a database
- Changing network configuration
- Upgrading middleware
- Modifying production infrastructure
- Implementing a permanent fix for a recurring incident
The objective is not simply to record work. Change Management is about controlling risk around modifications.
Example
Suppose an organization has identified a recurring integration failure.
The Problem Management team determines that the root cause is an outdated middleware configuration.
The permanent fix requires a production configuration change.
The implementation team therefore creates a Change Request containing:
- Change description
- Reason for change
- Configuration Item
- Implementation plan
- Testing plan
- Backout plan
- Risk and impact
- Planned start
- Planned end
- Assignment group
- Approval information
ServiceNow documentation/community material describes creating changes from incidents and problems, allowing relevant information such as the configuration item and other details to be carried into the change record.
Types of Change
Common change classifications include:
| Change type | Typical use |
|---|---|
| Standard | Pre-approved, repeatable, low-risk activity |
| Normal | Planned change requiring assessment/approval |
| Emergency | Urgent change required to address a critical situation |
The exact workflow and governance should be defined according to organizational policy and the ServiceNow configuration.
Real example
A company needs to deploy a new version of an integration service to production.
A normal change might contain:
Implementation Plan
- Stop integration scheduler.
- Deploy the new package.
- Update required configuration.
- Execute smoke tests.
- Monitor transactions.
Backout Plan
- Restore previous deployment.
- Restore previous configuration.
- Restart scheduler.
- Validate critical transactions.
This information allows the Change Advisory or approval process to evaluate the change before implementation.
4. Service Request Tickets
A Service Request is different from an Incident.
A service request usually represents something the user wants the organization to provide as part of its normal service offering.
Examples include:
- New laptop
- Software installation
- Application access
- Password reset
- New employee equipment
- Additional storage
- Standard account provisioning
ServiceNow describes service requests as requests for access to or fulfillment of an available service, rather than reporting that an existing service has failed.
Incident vs Service Request
Consider two employees.
Employee A:
“My laptop was working yesterday but will not start today.”
This is an Incident.
Employee B:
“I joined the marketing team and need a laptop.”
This is a Service Request.
The distinction is simple:
Something is broken → Incident
I need something provided → Service Request
Service Catalog relationship
Service Requests are commonly implemented through the Service Catalog.
For example:
Service Catalog → Hardware → Laptop Request
The requester provides information such as:
- Employee
- Department
- Manager
- Laptop type
- Business justification
- Required date
The request can then initiate fulfillment tasks.
A commonly encountered structure is:
REQ → RITM → Catalog Task
A catalog request can generate fulfillment tasks assigned to the appropriate teams.
How Incident, Problem, Change and Request Work Together
This is where ServiceNow becomes particularly useful in an enterprise implementation.
Consider a production application outage.
Stage 1 — Incident
Users report:
“Application unavailable.”
Service desk creates an Incident.
The support team restores the service.
Stage 2 — Problem
The same outage happens several times.
The support organization creates a Problem to identify the underlying cause.
Stage 3 — Change
The Problem investigation identifies a configuration defect.
A production change is required.
A Change Request is created.
Stage 4 — Incident Closure
After implementing the change, subsequent incidents stop occurring.
The Problem can eventually be closed after validating the permanent fix.
The overall relationship can therefore look like:
User Issue
|
v
Incident
|
| recurring issue
v
Problem
|
| permanent fix required
v
Change Request
|
| successful implementation
v
Problem ResolutionThis is a practical example of why ticket classification matters.
Other Important ServiceNow Record Types
The four ITSM categories above are the most commonly discussed, but ServiceNow is a broad platform.
Depending on the applications deployed, organizations may also work with other record types.
HR Cases
HR Service Delivery implementations commonly use cases for employee-related requests and issues.
Examples:
- Benefits questions
- Employee onboarding
- Payroll-related questions
- HR policy questions
- Employment documentation
These should not automatically be created as IT incidents.
Customer Service Cases
Customer Service Management uses cases to manage customer issues and requests.
For example:
Customer reports that an order has not been delivered.
This is generally a customer-service case rather than an internal IT incident.
Security Incidents
Security operations may use security incident records to track events requiring investigation.
Examples:
- Suspicious login
- Malware detection
- Unauthorized access
- Potential data exposure
The workflow and security controls can be considerably different from standard ITSM incidents.
Catalog Tasks
A Catalog Task is usually a fulfillment work item generated as part of a service request process.
For example:
Laptop Request
may generate:
- Manager approval
- Procurement task
- Asset preparation task
- Desktop support task
- Delivery task
The requester sees the overall request while different fulfillment teams work on their assigned tasks.
How to Decide Which Ticket Type to Create
A practical decision framework is more useful than memorizing definitions.
Ask these questions in sequence.
Question 1 — Is an existing service broken?
Yes → Incident
Example:
“Payroll application is unavailable.”
Question 2 — Is the organization investigating a recurring/root cause issue?
Yes → Problem
Example:
“The payroll application has failed four times this month.”
Question 3 — Is a controlled modification required?
Yes → Change
Example:
“Database parameter must be modified in production.”
Question 4 — Is the user requesting something that the organization normally provides?
Yes → Service Request
Example:
“Please provide access to the reporting application.”
This decision tree can be summarized as:
User Contact
|
Is something broken?
/ \
Yes No
| |
Incident Is something
being requested?
/ \
Yes No
| |
Service Request |
|
Is root cause
investigation needed?
/ \
Yes No
| |
Problem Evaluate
processConfiguration Overview for a ServiceNow Implementation
Ticket classification should not be designed independently from the organization’s operating model.
Before configuration, consultants should document:
1. Assignment groups
Examples:
- Service Desk
- Network Support
- Database Administration
- Middleware Support
- Oracle Application Support
- Security Operations
2. Categories
Define meaningful categories rather than creating hundreds of unnecessary choices.
Example:
Category: Application
Subcategory:
- Oracle Fusion
- ServiceNow
- Payroll
- Reporting
- Integration
3. Priority model
A common approach considers:
Impact + Urgency = Priority
The actual matrix should be approved by the organization’s ITSM governance team.
4. SLAs
Different ticket types may require different SLA definitions.
For example:
| Ticket | Business requirement |
|---|---|
| P1 Incident | Immediate response |
| P2 Incident | High-priority response |
| Standard Request | Fulfillment within defined business days |
| Problem | Investigation milestone |
| Change | Approval and implementation windows |
5. Assignment rules
Automation can route records based on:
- Category
- Configuration Item
- Service
- Location
- User department
- Priority
Step-by-Step: Creating and Classifying an Incident
The exact navigation can vary by ServiceNow release, application, workspace, and configured roles, so consultants should validate navigation in the target instance.
A typical approach is:
Step 1 — Open Incident Management
Navigate to the Incident workspace/application available to the assigned ITSM role.
Step 2 — Create an Incident
Enter information such as:
| Field | Example |
|---|---|
| Caller | John Smith |
| Short description | VPN unavailable |
| Category | Network |
| Impact | 2 – Medium |
| Urgency | 2 – Medium |
| Configuration Item | Corporate VPN |
| Assignment group | Network Support |
Step 3 — Add detailed information
Describe:
- What happened?
- When did it start?
- Who is affected?
- What troubleshooting has already been completed?
- Is there a workaround?
Step 4 — Save
The platform assigns the incident number.
For example:
INC0012345
Step 5 — Validate assignment
Confirm that the assignment rule routed the incident to the correct group.
Testing Ticket Classification
Testing should use real business scenarios rather than simply checking whether records can be created.
Test Case 1 — Service Failure
Input:
User cannot access corporate VPN.
Expected result:
Incident created and assigned to Network Support.
Test Case 2 — New Equipment
Input:
New employee requires laptop.
Expected result:
Service Request/catalog process initiated.
Test Case 3 — Recurring Failure
Input:
Same application has failed five times.
Expected result:
Incidents can be related to a Problem for root-cause investigation.
Test Case 4 — Production Fix
Input:
Configuration change required to permanently resolve the problem.
Expected result:
Change Request created and linked to the appropriate Problem/Incident.
ServiceNow supports relationships among these records so that operational teams can trace an issue from the reported symptom through investigation and remediation.
Common Implementation Challenges
1. Everything becomes an Incident
This is probably one of the most common classification problems.
For example:
“I need access to Oracle Analytics.”
Creating an Incident is usually inappropriate if the service itself is functioning normally.
Better approach: use a Service Request/catalog process.
2. Too many categories
Some implementations create hundreds of categories.
This makes reporting and routing difficult.
Use categories that actually support:
- Assignment
- Reporting
- SLA management
- Root-cause analysis
3. Problem Management is ignored
Teams often resolve incidents repeatedly without analyzing recurring failures.
The result is:
Incident → Incident → Incident → Incident
instead of:
Incident → Problem → Root Cause → Change → Permanent Resolution
4. Poor Change linkage
If a production change causes an incident, the organization should be able to identify the relationship between the Change and the resulting Incident.
This is especially important for operational reviews and change-risk analysis.
5. Catalog requests are poorly designed
A request form asking only:
“What do you need?”
creates additional work for fulfillment teams.
A well-designed catalog item should capture information required to fulfill the request from the beginning.
Best Practices for ServiceNow Ticket Management
1. Define classification rules
Create a simple decision matrix for service desk agents.
2. Separate break/fix from fulfillment
This single distinction prevents many classification errors.
3. Use Problem Management for recurring issues
Do not repeatedly resolve symptoms without investigating patterns.
4. Link related records
Maintain relationships between:
- Incident
- Problem
- Change
- Request
- Configuration Item
5. Keep forms focused
Only make fields mandatory when they are genuinely needed.
6. Automate routing
Use assignment rules and service/category information where appropriate.
7. Design SLAs around business impact
Avoid applying the same SLA to every ticket.
8. Build useful reporting
Track metrics such as:
- Incident volume
- Mean time to resolution
- Reopened incidents
- Recurring incidents
- Problem backlog
- Change success/failure
- Request fulfillment time
- SLA breaches
9. Train agents on classification
A technically correct ServiceNow configuration will still fail operationally if service desk users do not understand when to create each record type.
10. Review ticket data regularly
Look for patterns such as:
High number of incidents → recurring category → repeated Configuration Item → candidate Problem
This is where ticket data becomes operational intelligence rather than simply a collection of service desk records.
Real-World Implementation Scenario
Consider an organization running Oracle Fusion applications, corporate networking, identity management, and internal employee services.
An employee reports:
“I cannot access the Oracle Fusion application.”
The service desk first creates an Incident.
The support team discovers that the application itself is operational, but the employee does not have the required role.
Instead of treating this as an application outage, the team determines that the employee needs access.
The process becomes a Service Request or access request according to the organization’s service catalog design.
Now consider a different situation.
Hundreds of employees cannot access the application because a production identity integration is failing.
That is an Incident affecting a business service.
If the same integration failure occurs repeatedly, the organization should investigate it through Problem Management.
If the permanent solution requires modifying the production integration, that remediation is controlled through a Change Request.
This demonstrates the practical difference between the record types:
Incident = restore
Problem = investigate
Change = control the modification
Service Request = fulfill
Frequently Asked Questions
1. What are the main ticket types in ServiceNow?
The main ITSM categories commonly discussed are Incident, Problem, Change Request, and Service Request. Each has a different purpose and workflow. ServiceNow ITSM brings these management processes together on its platform.
2. What is the difference between an Incident and a Service Request?
An Incident generally represents an unplanned interruption or degradation of an existing service.
A Service Request generally represents a request for an available service, access, equipment, or standard fulfillment activity.
For example:
VPN stopped working → Incident
Request VPN access → Service Request
ServiceNow explicitly distinguishes service requests from incidents in this way.
3. Can an Incident create a Problem or Change?
Yes. In appropriate scenarios, an Incident can lead to a Problem or Change. This allows organizations to connect the initial service disruption with root-cause investigation and the eventual remediation.
Summary
Understanding ServiceNow ticket types is not simply a matter of memorizing four definitions. In an actual implementation, correct classification determines how work flows through the organization.
The core distinction is:
| Record type | Question it answers |
|---|---|
| Incident | How do we restore the service? |
| Problem | Why is this happening? |
| Change | How do we safely modify the environment? |
| Service Request | What standard service does the user need? |
A mature ServiceNow implementation connects these processes rather than treating them as isolated tickets.
For example:
Incident → Problem → Change → Permanent Resolution
At the same time:
User Requirement → Service Request → Fulfillment Tasks → Completion
For consultants, the most important practical lesson is to design ticket classification around the organization’s actual operating model, service catalog, assignment groups, SLAs, approval requirements, and reporting needs. Avoid excessive customization until the standard process has been understood and validated.
For additional ServiceNow product information, refer to the official ServiceNow IT Service Management documentation and product resources. For Oracle-related integrations with ServiceNow, also refer to the relevant Oracle Cloud documentation available through Oracle Documentation. Always validate navigation, field names, workflows, and available functionality against the version and applications enabled in your target ServiceNow instance.