IT Ticketing with ServiceNow

Create, work, and resolve incident tickets through the full ITIL lifecycle.

Introduction

30 Second Summary

Every time you report a broken laptop, a locked account, or a software crash at work, someone on the other end creates a ticket, works through it, and resolves it using a system like ServiceNow. These ticketing skills appear on nearly every IT support and help desk job description.

In this project, you will set up a free ServiceNow instance and work through the core tasks IT professionals do every day: creating and resolving incident tickets, building a self-service catalog item, managing change requests, and building operational reports.

What You'll Build

You will configure a ServiceNow ITSM environment and complete the full ITIL incident lifecycle from ticket creation to resolution.

By the end of this project, you'll have:

A fully resolved incident ticket with work notes, resolution notes, and a complete audit trail.
A service catalog item published to the self-service portal with custom intake variables.
An approved change request demonstrating the change management workflow with a test plan and backout plan.
An operational report showing incident volume by priority for data-driven decision making.
Secret Mission: Create a Problem record linked to your incident that documents root cause analysis and a permanent fix.

Are there any prerequisites?

None. This project includes full setup instructions for everything you need. All you need is a web browser and an email address to create your free ServiceNow developer account.

Set Up Your ServiceNow Developer Instance

ServiceNow is the platform that most large enterprises use for IT ticketing and service management. Getting hands-on with it is one of the fastest ways to stand out for IT support and help desk roles.

In this step, you will create a free ServiceNow Developer account and provision your own Personal Developer Instance (PDI). This gives you a private, fully functional ITSM environment to practice in.

In this step, get ready to:

Create a ServiceNow Developer account with the Admin role.
Provision a Personal Developer Instance on the Yokohama release.
Log in and verify the instance is accessible.

Create your ServiceNow Developer account

ServiceNow offers a free Developer Program that includes a personal sandbox instance. You need an account on their developer site before you can request one.

Open your browser and go to developer.servicenow.com.
Click Sign In in the top right corner.
Click Get a ServiceNow ID to start the registration form.
Complete the sign-up form with your email address and a password.
Check your inbox for the verification email and click the verification link.
Return to the Developer Site and sign in with your new credentials.

On your first login, ServiceNow asks you to set up your profile.

On the Hello, Help us tune your experience. screen, select Yes when asked "Do you code?" to choose the Admin user role.
Agree to the Developer Site Terms of Use.
Click Finish Setup.

Why choose the Admin role?

ServiceNow offers two roles: Admin (unrestricted access to the full platform) and App Engine Studio Creator (restricted to a simplified app builder). For this project, you need the Admin role to access the Incident, Change, Problem, and Report modules.

Didn't receive the verification email?

Check your spam or junk folder. The email comes from ServiceNow and can take a minute or two to arrive. If it still hasn't shown up after five minutes, try re-entering your email on the sign-up page.

Help me troubleshoot my ServiceNow Developer account sign-up.

Request your Personal Developer Instance

A Personal Developer Instance (PDI) is a fully functional ServiceNow environment that belongs to you. It comes pre-loaded with demo data so you can practice with realistic records.

Click the Request Instance button in the Developer Site header.
In the Request an Instance dialog, select the Yokohama release (or the latest available release if Yokohama is not listed).
Click Request.
Wait for the "Your instance is ready!" dialog to appear. This can take a few minutes.

The dialog displays three critical pieces of information you need to save.

Copy and save your instance URL (format: dev12345.service-now.com, where the numbers are unique to you).
Copy and save your Username (typically admin).
Copy and save your Current Password to a secure location.

Save these credentials now

Paste your instance URL, username, and password into a text file or password manager immediately. You will need them every time you access your instance. You can also find them later via the Manage my Instance button in the Developer Site header.

What is a PDI?

A Personal Developer Instance is a free, admin-level sandbox of the full ServiceNow platform. It includes demo users, pre-configured categories, and sample data so you can practice without affecting a real company's environment.

Your PDI stays active as long as you sign in to the Developer Site at least once every 10 days. If it goes idle, it hibernates to save resources but your data is preserved. Signing in again wakes it up.

Instance taking a long time?

Provisioning usually takes 1-3 minutes but can occasionally take up to 10-15 minutes during high demand. Do not refresh the page while waiting. If it takes longer than 15 minutes, try releasing the request and starting again.

Help me troubleshoot my ServiceNow PDI provisioning.

Log in and verify your instance

Now that your instance is provisioned, you need to open it and confirm you can access the full platform interface.

Click Open Instance in the "Your instance is ready!" dialog. This opens your PDI in a new browser tab.
Verify you can see the All menu (also called the application navigator) on the left side of the screen.
Type Incident in the filter navigator field at the top of the left sidebar.
Confirm that Incident menu options appear (including Create New and All).

What is the application navigator?

The application navigator is the left sidebar in ServiceNow's platform view. You use the filter field at the top to quickly find any module by typing its name. This is the primary way you will navigate ServiceNow throughout this project.

Seeing App Engine Studio instead of the full platform?

If your PDI opens to App Engine Studio (a simplified interface without the left sidebar navigator), your user role needs to be changed to Admin. Here is how to fix it:

Go back to the Developer Site tab (developer.servicenow.com).
Click your avatar in the header to open the Account menu.
In the INSTANCE ACTION section, click Change User Role.
Select Admin and click the Change User Role button.
Close your PDI browser tab, then click Start Building in the Developer Site header to relaunch your instance.

Help me switch my ServiceNow PDI from App Engine Studio to the full Admin platform view.

Your ServiceNow environment is ready to go. Next up, you will create your first incident ticket and work it through the full ITIL lifecycle from creation to resolution.

Create and Work an Incident Ticket

Your ServiceNow instance is live and ready. Now it's time to do what IT support professionals do dozens of times a day: create and resolve an incident ticket.

An incident in ITIL is any unplanned interruption to a service. You'll create one from scratch, document the diagnostic work, and close it out with a full resolution trail.

In this step, get ready to:

Create a new incident ticket with proper categorization and priority.
Work the incident by adding diagnostic work notes.
Resolve and close the incident with full resolution documentation.

Create a new incident

Every incident starts with someone reporting a problem. You'll simulate a help desk call by logging a ticket for a user who can't access their email.

In the application navigator (left sidebar), type Incident in the filter field.
Select Create New under the Incident module.
In the Caller field, type Abel Tuter and select the matching user from the dropdown.
Set Category to Software.
Set Subcategory to Email.
In the Short description field, enter User cannot access Outlook - error: Cannot connect to server.
Set Impact to 2 - Medium.
Set Urgency to 3 - Low.
Set Assignment Group to Service Desk.
Click Submit.

After submitting, note the ticket number displayed at the top of the page. It follows the format INC0010001 (your specific number may differ).

How does Priority get calculated?

You did not set Priority directly. ServiceNow calculates it automatically using a matrix of Impact multiplied by Urgency. With Impact = 2 (Medium) and Urgency = 3 (Low), the system assigns Priority 3 - Moderate.

This matrix ensures consistent prioritization across all tickets, no matter which agent logs them.

Don't see Abel Tuter in the Caller dropdown?

Abel Tuter is a built-in demo user. If the name does not appear, start typing it and wait a moment for the reference lookup to query the user table. If it still does not appear, select any other user from the list to continue.

help me find a user in the Caller field

Work the incident through its lifecycle

A ticket sitting in New status means nobody is working on it yet. Moving it to In Progress signals to the team that an agent has picked it up.

Open your incident from the incident list. You can type Incident in the application navigator and select All to see all incidents.
Click on your incident number (e.g. INC0010001) to open it.
Change the State field to In Progress.
Set the Assigned to field to your admin user (the account you are currently logged in as).
Click Update to save these changes.

Now add a work note to document your diagnostic steps. Open the incident again.

Scroll down to the Work Notes field (under the Activity section).
Paste the following text into the Work Notes field:

Contacted user. Confirmed error. Outlook profile appears corrupted. Attempting profile repair. User instructed to use OWA in interim.

Click Update to save the work note.

What are Work Notes?

Work Notes are internal communications visible only to IT staff. They document diagnostic steps, coordination between agents, and progress updates. The caller (end user) never sees them.

If you need to communicate with the caller, use the Additional Comments field instead. That field sends a notification to the user.

Resolve and close the incident

You've diagnosed the problem and applied a fix. Now you need to document the resolution and close the ticket.

Open your incident again from the incident list.
Change the State field to Resolved.

Why do new fields appear?

When you set the state to Resolved, ServiceNow makes the Resolution code and Resolution notes fields mandatory. This is an out-of-the-box Data Policy that enforces documentation before a ticket can be closed.

If a Resolution code field appears, set it to Solved (Permanently) or the closest available option.
In the Resolution notes field, paste the following:

Rebuilt Outlook profile. Removed corrupted OST file. Outlook recreated OST on next launch. User confirmed working.

Click Update to save.
Open the incident one more time. Change the State to Closed.
Click Update.

Scroll down to the Activity section on your closed incident. You should see the full audit trail showing every state transition, your work note, and the resolution notes.

Why does ITIL separate Resolved from Closed?

Resolved means a fix has been applied but the user has not yet confirmed the service is restored. Closed means the user has confirmed everything is working. This two-step process creates an accurate operational history.

In a real environment, the ticket would stay in Resolved until the caller confirms the fix. For this project, you're acting as both the agent and the caller.

Can't change state to Resolved?

ServiceNow requires certain fields before allowing the Resolved state. Make sure the Resolution notes field is filled in. If you see mandatory field warnings (indicated by red text or asterisks), fill in the highlighted fields before clicking Update.

help me resolve my ServiceNow incident

You've just completed the full incident lifecycle. Next up, you'll build a service catalog item that lets users submit requests without calling the help desk.

Build a Service Catalog Item

Your incident ticket is closed and fully documented. Now it's time to reduce the number of tickets like that from ever reaching the help desk in the first place.

A service catalog gives users a self-service portal where they can submit structured requests without calling or emailing IT. In this step, you'll build a "New Laptop Request" catalog item that collects exactly the information IT needs to fulfill the request.

In this step, get ready to:

Create a service catalog item for laptop requests.
Add custom intake variables that collect requester details.
Verify the catalog item works in the self-service portal.

Create a New Laptop Request catalog item

Catalog items are pre-built request forms that appear in the self-service portal. Each item collects the right information upfront so IT can process requests without back-and-forth emails.

In the application navigator (left sidebar), type Maintain Items in the filter field.
Select Service Catalog > Maintain Items from the results.
Click New to create a new catalog item.

Fill in the following fields on the catalog item form:

Set Name to New Laptop Request.
Set Short description to Request a new or replacement laptop.
Set Category to Hardware.
In the Description field, enter a full description explaining the request process. Mention that requests are reviewed within 2 days and delivery takes 5-7 business days.
Click Submit.

What is a service catalog item?

A catalog item is a predefined service offering that appears in the employee self-service portal. Think of it like an item in an online store, but instead of products, users are ordering IT services.

Each item has its own intake form, approval workflow, and fulfillment process. This means the IT team receives structured, complete requests every time instead of vague emails.

Add intake variables to the catalog item

Variables are the form fields that users fill out when they submit a request. You need to add them so the laptop request collects all the details IT needs to process it.

Open your New Laptop Request catalog item from the Maintain Items list.
Click the Variables tab at the bottom of the record.

Variables tab not visible?

The Variables tab only appears after you have saved the catalog item at least once. If you don't see it, make sure you clicked Submit in the previous substep and then re-opened the item.

Add each of the following variables by clicking New in the Variables tab:

Click New to add the first variable.
Set Type to Single Line Text.
Set Question to Requester Name.
Check the Mandatory checkbox.
Click Submit.

Repeat this process three more times for the remaining variables:

Variable 2: Type = Multi Line Text, Question = Business Justification, Mandatory = checked.
Variable 3: Type = Date, Question = Required By Date, Mandatory = checked.
Variable 4: Type = Select Box, Question = Laptop Model Preference, Mandatory = unchecked. After submitting, open this variable and add three choices: Standard, Developer, and Executive.

Why make some fields mandatory?

Mandatory fields ensure IT always receives the critical information needed to process the request. Without a business justification, for example, the approval team has no basis to approve or deny the purchase.

The laptop model preference is optional because not every requester has a preference. Keeping it optional prevents unnecessary friction for users who just need any available machine.

Variable not saving?

Make sure you click Submit (not just Save) after filling in each variable. Also confirm you selected a Type before entering the Question field. Help me troubleshoot my catalog item variables.

Verify the catalog item in the self-service portal

The self-service portal is what end users actually see when they submit requests. You need to confirm your catalog item appears correctly and creates a ticket when submitted.

Navigate to the self-service portal by adding /sp to the end of your instance URL (for example, dev12345.service-now.com/sp).
Search for New Laptop Request in the portal search bar.
Click on your catalog item to open it.
Verify all four variables appear as form fields.
Fill in test values for each field and click Submit.
Confirm you receive a request number (format: REQ followed by digits) indicating the workflow created a ticket.

What is the /sp portal?

The /sp path opens the ServiceNow Service Portal. This is the user-facing front end that employees interact with. It is separate from the admin platform UI you have been using to build and configure things.

Think of it as the storefront vs. the back office. You build the catalog item in the admin UI, but end users browse and order from the portal.

Catalog item not appearing in the portal?

Make sure you set a Category (Hardware) on the catalog item. Items without a category may not appear in portal searches. Also confirm the item is in the Active state by checking the Active checkbox on the item record. Help me find my catalog item in the ServiceNow portal.

Your service catalog item is live and ready for users. Next up, you'll create a change request with an approval workflow to see how IT teams manage production changes safely.

Create a Change Request with Approval

Your self-service catalog item is live and ready for user requests. Now it's time to tackle one of the most critical ITSM workflows: change management.

In IT operations, every modification to production systems must be documented and authorized before implementation begins. You'll create a change request for a routine security patch, add planning details, and walk it through the approval workflow.

In this step, get ready to:

Create a standard change request with scheduling details.
Add a test plan and backout plan to the Planning tab.
Submit for approval and approve the change as admin.

Create a standard change request

A change request is a formal proposal to modify something in a production environment. Even a routine security patch needs documented authorization so teams can coordinate, plan for downtime, and roll back if something goes wrong.

In the application navigator on the left sidebar of your ServiceNow instance, type Change in the filter field.
Select Create New from the Change menu options that appear.

A new change request form opens. Fill in the following fields:

Set Short description to Deploy security patch to all Windows workstations.
Set Category to Software.
Set Risk to Low.
Set Impact to 2 - Medium.
Set Start date to next Saturday at 2:00 AM.
Set End date to next Saturday at 6:00 AM.

In the Description field, explain the patch purpose. For example: Monthly Windows security patch deployment. All workstations require one reboot to complete installation. Scheduling during off-hours to minimize user disruption..
Click Submit to save the change request.

Why schedule changes during off-hours?

Production changes are scheduled during maintenance windows (like Saturday 2:00-6:00 AM) to minimize impact on users. If something goes wrong, the IT team has time to roll back before the workday begins.

Don't see Change in the navigator?

Make sure you are logged in with the Admin role. If your instance opened to App Engine Studio, you need to switch to the full platform view to access Change modules.

help me find the Change module in my ServiceNow navigator

Add planning details and request approval

Every change request needs a test plan and a backout plan. The test plan describes how you'll verify the change works. The backout plan describes how you'll undo it if something breaks.

Open your change request from the Change list (type Change in the navigator and select All to find it).
Click the Planning tab on the change request form.

In the Test Plan field, enter: Deploy to 5 pilot workstations first. Verify no application compatibility issues before full rollout..
In the Backout Plan field, enter: Uninstall patch via WSUS if issues reported. Estimated rollback: 2 hours..
Click Request Approval to submit the change for authorization.

The change request state moves to Pending Approval. No one can implement this change until it receives documented authorization.

Why do changes need a backout plan?

In ITIL change management, every change must have a documented rollback strategy. If a patch causes application crashes or network outages, the team needs a pre-approved path to undo the change quickly.

Without a backout plan, approvers should reject the change. This is a real governance control you'll encounter in enterprise IT.

Don't see the Request Approval button?

Make sure you've saved the change request first by clicking Save or Update before looking for the approval button. The button may appear in the top-right area of the form or in the actions bar.

help me find the Request Approval button on my change request

Approve the change and verify the workflow

In a real organization, someone other than the requester approves changes. Since you're the only user on your developer instance, you'll act as both the requester and the approver.

On your change request, click the Approvals tab.
Find the approval record listed for your admin user.
Click Approve to authorize the change.

Verify that the change request state has moved from Pending Approval to Scheduled.

The state transition from Pending Approval to Scheduled confirms that the approval workflow is functioning. The change is now authorized and waiting for its maintenance window to begin.

What does this demonstrate about ITIL?

This workflow enforces a core ITIL principle: production changes require documented authorization before implementation begins. The approval gate prevents unauthorized modifications that could cause outages or security gaps.

In enterprise environments, different change types (standard, normal, emergency) have different approval requirements. The standard change you just created follows the full approval path.

State didn't change to Scheduled?

Refresh the page after approving. If the state still shows Pending Approval, check whether additional approvers are required by looking at the Approvals tab for other pending records. Your PDI may have a multi-level approval configuration.

help me troubleshoot why my change request isn't moving to Scheduled after approval

Your change request is approved and scheduled. You've now worked through the full change management lifecycle. Next up, you'll build operational reports to visualize your ITSM data and extract actionable insights.

Build an Operational Report

Your change request is approved and scheduled. You now have hands-on experience with incident management, service catalog design, and change control. The final piece of the ITSM puzzle is reporting.

IT managers need data to make staffing, training, and investment decisions. ServiceNow reports turn raw ticket data into visual summaries that answer questions like "where are we spending the most time?" and "which problems keep coming back?" In this step, you will build two operational reports that demonstrate this skill.

In this step, get ready to:

Create a bar chart report showing incident volume grouped by priority.
Build a pie chart report showing open incidents grouped by category.
Interpret both reports for operational decision-making.

Create an Incident Volume by Priority report

This report will show how many incidents fall into each priority level. A healthy IT operation has mostly low-priority tickets. If high-priority tickets dominate, that signals systemic problems.

In the application navigator (left sidebar), type Reports in the filter field.
Select Reports > Create New.
Set Name to Incident Volume by Priority.
Set Data source to Incident [incident].
Set Type to Bar Chart.
Set Group by to Priority.

What does Group by do?

The Group by setting determines how the report splits your data. Grouping by Priority creates one bar for each priority level (Critical, High, Moderate, Low, Planning). Each bar's height represents the number of incidents at that priority.

Under the Conditions section, add a filter: Created on or after 90 days ago.
Click Save and then click Run.

You should see a bar chart with colored bars representing each priority level. The demo data in your instance provides enough incidents to populate the chart.

Not seeing any data in the chart?

Make sure your Data source is set to Incident [incident] and not another table. Also check that your condition says "on or after" rather than "on or before." If the chart is still empty, try removing the condition entirely to see all incidents.

Help me troubleshoot my ServiceNow report showing no data

Build a second report for open incidents by category

Your first report shows overall volume. This second report focuses on where current support demand is concentrated by showing only open incidents, grouped by their category.

Navigate back to Reports > Create New using the application navigator.
Set Name to Open Incidents by Category.
Set Data source to Incident [incident].
Set Type to Pie Chart.
Set Group by to Category.

Now add two conditions to filter down to only the tickets that are currently open.

Under Conditions, add the first filter: State is not Closed.
Add a second filter: State is not Resolved.
Click Save and then click Run.

You should see a pie chart with slices for each category (Software, Hardware, Network, etc.). The size of each slice represents how many open incidents exist in that category.

Why exclude both Closed and Resolved?

In ServiceNow, Resolved means the fix has been applied but the caller has not confirmed it works yet. Closed means the ticket is fully done. Excluding both gives you only the tickets that still need active attention.

Pie chart showing only one slice?

If most demo incidents share the same category, the chart might look like one large slice with a tiny sliver. This is normal with demo data. The report structure is correct as long as data appears.

Help me check if my ServiceNow pie chart report is configured correctly

Interpret your reports for operational decisions

Creating reports is only half the skill. IT managers expect their team to explain what the data means and recommend actions based on it.

Review your Incident Volume by Priority report.
Note which priority level has the tallest bar.
Review your Open Incidents by Category report.
Note which category has the largest slice of the pie.

How do IT managers use these reports?

The Priority report reveals whether the team is firefighting (too many P1/P2 tickets) or handling routine work (mostly P3/P4). If high-priority tickets dominate, that signals systemic infrastructure problems that need investment.

The Category report shows where to invest in self-service portals, automation, or training. If Software incidents dominate, building knowledge base articles or catalog items (like you did in Step 3) can deflect those tickets before they reach the help desk.

Secret mission

Create a Problem Record from Your Incident

Your incident is resolved, but what caused the Outlook corruption in the first place? In ITIL, a Problem is the root cause behind one or more incidents. Creating a Problem record demonstrates you understand the difference between restoring service (incident) and eliminating the underlying cause (problem).

Clean Up Your Resources

This project runs entirely on a free ServiceNow Personal Developer Instance, so there are no ongoing costs. Decide whether to keep your instance active, let it hibernate, or release it entirely.

Resources you used:

ServiceNow Personal Developer Instance (PDI) at dev[number].service-now.com.

Keep everything running

No action needed if you plan to keep building in ServiceNow. Your instance, tickets, catalog items, reports, and all configuration stay exactly where they are.

Log in to developer.servicenow.com at least once every 10 days to prevent your instance from being reclaimed.
If you miss the 10-day window, your instance is reclaimed and reassigned to another developer. All your data is lost in that case, so set a reminder if you want to keep it.

Pause - I'll come back to this later

If you go idle for a few days, your instance automatically hibernates to save resources. All your data is preserved.

When you are ready to return, sign in at developer.servicenow.com and your instance wakes up.
Waking your instance resets the 10-day inactivity countdown.
You do not need to do anything special to trigger hibernation. It happens automatically after a period of idle time.

Delete - I don't want to use this again

If you are finished with ServiceNow and do not plan to return, you can release your instance. This resets the instance and makes it available to another developer.

Go to developer.servicenow.com and sign in.
Navigate to the Manage Instance page.
Click Release Instance under the Actions menu.
Your instance and all data (tickets, catalog items, reports, problem records) are permanently deleted.
You can always request a new instance later if you change your mind.

Nice Work!

You did it! You now have hands-on ServiceNow ITSM experience that maps directly to IT support, help desk, and cloud operations job descriptions.

You've learned how to:

Created and resolved an incident ticket through the full ITIL lifecycle (New, In Progress, Resolved, Closed) with work notes, resolution notes, and a complete audit trail.
Built a self-service catalog item with custom intake variables and created an approved change request with test and backout plans, demonstrating change management discipline.
Built operational reports showing incident volume by priority and category, proving you can extract actionable intelligence from ITSM data.
💎 Created a Problem record with root cause analysis, workaround, and permanent fix, completing the ITIL incident-to-problem-to-known-error escalation path.

Ready to quiz yourself?