The request engine in ServiceNow is often misunderstood.
What is a request? What is a requested item? How are they different from incidents?
These common questions are often never addressed and people are too afraid to ask them.
In short, ServiceNow can be used to request “items” from a Service Catalog, usually in a portal. A Service Catalog is a list f items that the user can request. When these items are requested to be delivered, whether it’s software or hardware – the user is submitting a request. It is the ordering of the asset, and the workflow automation behind it, that encapsulates the request space in ServiceNow.
Task is the base/parent table for these records. Task is one of 2 base tables in ServiceNow, the other being the CMDB [cmdb_ci].
In ServiceNow, users can request “things”. If you’re an employee of a company – you can request a new computer, a certain software, etc.
The Request space works in a Parent/Child Relationship structure.
Per ITIL, requests are typically only for hardware and software requests. Although it’s likely fine if you’re company moves to related spaces and keeps them in a Request.
Let’s use a simple example to ensure that we understand Requests.
Understanding The ServiceNow Request Engine
The structure goes as follows: Request > Requested Items > Catalog Tasks.
The ServiceNow request based terminology goes as follows: Request (REQ), Requested Item (RITM), Catalog Task (TASK) or (CTASK).
You can better understand the relationship by scrolling to the bottom of each form, and seeing the “child” record(s).
For example, at the bottom of the REQ, are the RITM’s. At the bottom of the RITM’s are the CTASK’s.
Below is an example of a Related List, at the bottom of a RITM record.
What is a Request?
There is always one parent request record. A request is simply a task.
This is more so a placeholder, and allows records to be nested underneath it. Communication does not tend to occur at this level, it tends to occur at the RITM and CTASK.
The important fields on this form are usually the Approval state and the Requested For.
What is a Requested Item?
Under any single request in ServiceNow, there can be one or multiple requested items.
A requested item is simply the tangible software/hardware item that’s being requested.
This is usually where the Workflow is connected to an item.
The variables that were selected for each item, tend to be placed here. But this is customizable per each ServiceNow instance.
The important fields on this form are usually the Approval state, The Catalog Item and the Requested For.
What is a Catalog Task?
And then under each requested item are Catalog Tasks.
Catalog Tasks are measurable and repeatable units of work that need to be completed, usually in order to deliver a Requested Item.
Whenever you see task in ServiceNow, think “a repeatable action to complete”.
For example, if a computer is being ordered, multiple Catalog Tasks would be created, usually one after the other. One might be for sourcing the computer. The next might be for imaging the computer. The last might be for shipping the computer. So these are units of work that need to be completed.
You can visualize the relationship by scrolling to the bottom of each form.
An Example Of A ServiceNow Request
So say for example you’re a new employee, and your manager is ordering a new laptop, a new monitor, and a cell phone for you.
Requests are usually created from Catalog Items in the ServiceNow Service Portal. All users at a company will have access to this portal.
If you fill out the form for what items you are going to order – you would have one Request, and 3 Requested Items. One requested item for each item. And then as many catalog tasks, under each RITM, for the work that needs to get done to get the Requested Item completed/delivered.
Catalog Tasks are just actions that need to take place, to deliver the asset to the user.
Once the Catalog Tasks are completed, the custom workflow connected to the catalog item will come to a Finished state.
Every ServiceNow environment is configured a little differently, especially around the procurement and ordering space.
What works for 90% of companies is to take what is out of box (OBB) and gently modify it to fit your needs. It’s important to stay close to out of box and not go crazy with the customizations.
In short order, this completes the post on requests.
The above can be tough to get your head around, but it’s how the Request space works.
Let us know below if you’re company uses the Request space in a different way.
very nice, I was looking for a related article explaining how current state conditions work in the UI Actions of incidents.