Service Catalog in ServiceNow
If you have worked in any IT organization, you already know the chaos — someone sends an email to request a laptop, another person calls the helpdesk for VPN access, and nobody knows the status of anything. This is exactly the problem Service Catalog solves.
Let Me Start With a Real Situation
Imagine a new employee joins your company on Monday. By Tuesday morning, they need:
- A laptop configured with company software
- An email account
- VPN access to connect remotely
- Access to development tools
Without a Service Catalog, this person sends four different emails to four different teams. Some get lost. Some are delayed. Nobody knows who is responsible for what.
With Service Catalog? They open the portal, select each service, submit the requests in one place, and the system automatically routes everything to the right teams. Simple. Clean. Trackable.
That is the power of Service Catalog in ServiceNow.
So What Exactly is a Service Catalog?
Think of Service Catalog like an online shopping website — but instead of buying products, employees are requesting IT services.
Just like how you browse Amazon, add items to cart, and checkout — an employee opens the Service Portal, browses available services, selects what they need, fills a short form, and submits. That's it.
Behind the scenes, ServiceNow handles everything — approval routing, task assignment, notifications, and tracking.
Simple Definition:
A Service Catalog is a self-service portal where employees can browse and request IT services without calling or emailing the support team directly.
Common Examples of Service Catalog Requests
Before we go deeper, let me show you what kind of services are typically available in a Service Catalog:
| Category | Service Examples |
|---|---|
| Hardware | Laptop request, Hardware replacement, Keyboard/Mouse |
| Software | Software installation, License request, Tool access |
| Access Requests | VPN access, Email account, Application access |
| IT Support | Password reset, Network issue, Printer setup |
These are not random — every organization decides which services go into the catalog based on what their teams commonly request.
The Building Blocks — Components of Service Catalog
This is where most beginners get confused. Service Catalog is not just one thing — it has multiple components that work together. Let me explain each one clearly.
1. Catalog
The Catalog is the top-level container. Think of it as the entire store itself.
An organization can have multiple catalogs — one for IT services, one for HR services, one for Finance. Each catalog holds its own set of services.
Example: IT Service Catalog, HR Service Catalog
2. Categories
Categories are the sections inside a catalog — like aisles in a supermarket. They help users find services quickly without searching through everything.
Example: Inside IT Service Catalog, you might have categories like Hardware, Software, Access Requests, and IT Support.
3. Catalog Items
A Catalog Item is the actual service that a user can request. This is what the user clicks on, fills a form for, and submits.
Each catalog item has:
- A name and description
- A request form with relevant questions
- A workflow or flow that runs after submission
- Approval steps if needed
Example: "Request a Laptop" is a catalog item. When clicked, it opens a form asking — What type of laptop? Which department? Needed by when?
4. Record Producers
This one is lesser-known but very useful. A Record Producer looks like a Catalog Item to the user, but instead of creating a Service Request, it creates a record in another table — like Incident or Problem.
Example: A user submits a "Report an Issue" form from the portal. Instead of creating a request, it creates an Incident record directly in the incident table. The user doesn't know the difference — but the backend handles it properly.
Record Producers are useful when you want users to submit things through the portal but have the data go directly into operational tables.
Quick Way to Remember:
Catalog Item → Creates a Request (RITM) record
Record Producer → Creates a record in any table (Incident, Problem, etc.)
Step by Step — How Service Catalog Works
Now let me walk you through exactly what happens when a user submits a request through the Service Catalog. I will keep this simple.
User Opens the Service Portal
The employee logs in to the ServiceNow portal — usually available at your company's internal URL. They see a clean interface with categories and a search bar.
User Browses and Selects a Service
They browse through categories or search for what they need. They click on the Catalog Item — for example, "Request VPN Access."
User Fills the Request Form
A form opens with specific questions related to that service. For VPN, it might ask — Which region? Full-time or temporary access? Business justification?
Request is Submitted
User clicks Submit. ServiceNow creates a Request (REQ) and one or more Requested Items (RITM) in the background. The user gets a confirmation with a reference number.
Approval Process (if configured)
If the catalog item requires approval, the manager or approver gets a notification. They approve or reject the request from their email or portal.
Request Assigned to Team
After approval, the workflow assigns the task to the correct fulfillment team. For VPN access, it might go to the Network team automatically.
Request is Fulfilled and Closed
The team completes the task and marks it as fulfilled. The user gets a notification. The request closes. Everything is tracked and auditable.
Why Organizations Love Service Catalog
Here is what actually changes when a company properly implements Service Catalog:
- No more email chaos — every request goes through one system
- Standardized forms — teams always get the information they need upfront
- Automatic routing — no manual assignment, workflow handles it
- Full visibility — users can track their request status anytime
- Faster fulfillment — automated approvals cut down wait time significantly
- Better reporting — management can see which services are most requested
One Thing Most Blogs Don't Tell You
Here is something I wish someone told me early on —
The difference between a good Service Catalog and a bad one is not the tool. It is the design of the catalog items.
I have seen catalogs with 200+ items where users cannot find anything. I have also seen catalogs with 15 well-designed items where everyone knows exactly where to go.
A good catalog item:
- Has a simple, clear name — "Request Laptop" not "Hardware Asset Procurement Form"
- Asks only the questions that are truly needed
- Has a realistic fulfillment time clearly mentioned
- Sends proper notifications at every stage
- Closes automatically when done — no manual closing by admins
If your catalog item is confusing, users will call the helpdesk anyway — which defeats the whole purpose.
Interview Questions on Service Catalog
Q. What is the difference between a Catalog Item and a Record Producer?
A. A Catalog Item creates a Service Request (RITM) record in the sc_req_item table. A Record Producer also appears in the Service Catalog but creates a record in a different table — such as Incident or Problem. Record Producers are used when you want the user to submit through the portal but route the data to operational tables.
Q. What is REQ and RITM in Service Catalog?
A. REQ is the Request record — the parent. RITM (Requested Item) is the child record representing each individual catalog item requested. One REQ can have multiple RITMs — for example, if a user requests a laptop AND VPN access in the same order, one REQ is created with two RITMs.
Q. Can a Service Catalog item work without a workflow?
A. Technically yes — a catalog item can be submitted without a workflow. But in practice, every catalog item should have either a Workflow or Flow Designer configured to handle approvals, assignments, and fulfillment automatically. Without it, someone has to manually process every request.
Key Takeaways
- ✔ Service Catalog = self-service portal for IT service requests.
- ✔ Components: Catalog → Category → Catalog Item → Record Producer.
- ✔ Catalog Item creates RITM, Record Producer creates records in other tables.
- ✔ The workflow handles approvals, assignments, and fulfillment automatically.
- ✔ A good catalog design matters more than the tool itself.
- ✔ REQ is parent, RITM is child — one REQ can have multiple RITMs.
