Procedure for Identifying Unrequested Catalogs: An Empirical Measurement of a 98.6% Dead Stock Rate

What percentage of items published in the service catalog are actually being ordered? Many operational teams work without knowing the answer. This is because once a catalog is published, deleting or consolidating it is often put on the back burner.

In this PDI, out of 148 active catalog items, only 2 types had been ordered in the last 180 days. The remaining 146 items, a ratio of 98.6%, are in a state of being "published but never requested." This is a shockingly low figure. I will explain the details of this figure, starting with the basic knowledge from official documentation and then moving to the actual machine screen.

What you will learn in this article

• How service catalog items (sc_cat_item) and orders (sc_req_item) are officially linked

• Out of 148 active items, how many were ordered in the last 180 days (actual measurement on a live instance)

• What can and cannot be understood just by using list filters

• A diagnostic script to perform the same inventory check in your own environment (paid section)

Service Catalog Basics: The Relationship Between Items and Orders

Each item listed in the service catalog is a record in the sc_cat_item table. When a user clicks the "Order Now" button, the request is created as an sc_request (Request) and an associated sc_req_item (Request Item, commonly known as RITM). Each RITM is linked one-to-one to the originating catalog item via a reference field called cat_item. In other words, the design allows you to determine whether a specific item has been ordered by counting the cat_items on the RITM side.

The official Service Catalog items (Zurich) documentation defines catalog items as "orderable units" such as hardware, software, or services. There are multiple types of items, ranging from simple application forms to record producers that create records directly in other tables.

For detailed classifications, please refer to Types of catalog items (Zurich) .

sc_cat_item has two fields that serve as clues for inventory checks. One is the owner (a reference field), which points to the person in charge of that item.

The other is the mechanism that determines post-order processing. There are two types: workflow, which points to a legacy workflow, and flow_designer_flow, which points to a Flow Designer flow. If either one is configured, approvals and task generation will run upon ordering.

If both are empty, it means only the order form exists, and no backend processing has been configured.

The mechanism of the workflow editor is summarized in Workflow editor (Zurich) . The structure of Flow Designer is explained in Flow Designer Architecture Overview (Zurich) .

Verifying on a Live Instance: Number of Active Catalog Items

Open the Catalog Items list and set Active to true to filter for only currently published items.

In this PDI, there were a total of 198 sc_cat_item records, 148 of which were Active. The breadcrumb at the top left of the list shows All > Active = true, and you can also confirm that there are 148 items in the count display at the bottom of the screen.

On the other hand, there are only 8 RITMs (sc_req_item) that have actually been requested in total. Narrowing it down to the last 180 days, there are 3, and they involved 2 types of items. Out of 148 Active items, only 2 types were ordered in the last 180 days. This contrast forms the basis for the following dead stock rate.

The screen for creating new catalog items has an Owner field provided by default.

The creator's user is entered as the default owner, but the value can also be saved as blank. If this field is empty for items currently in operation, it becomes unclear who to ask for decisions regarding retirement or consolidation.

I will show the figures for this point in the second half.

Why you cannot immediately conclude that "no orders" equals "unnecessary"

Looking only at the 98.6% figure, one might think, "I should just unpublish the remaining 146 items all at once." However, this judgment has premises that are easy to overlook. There are three reasons.

First, catalog items have a mechanism called User Criteria that controls visibility. Items narrowed down to be visible only to specific departments or job titles are not seen by the majority of users in the first place. It is possible that they are not unrequested, but simply not visible. The configuration method is explained in the official Apply user criteria to items and categories (Zurich).

Next, the aggregation in this article only looks at the cat_item field of sc_req_item. Requests made via Order Guides that order multiple items together or via Record Producers may not be directly linked to a cat_item.

Orders that pass through this path are omitted from this aggregation.

Furthermore, the 180-day judgment period itself has premises. Seasonal items that are requested only once a year (such as equipment updates at the end of the fiscal year) will look like "dead stock" within a 180-day window.

For these three reasons, the figure of 146 items is a candidate for inventory review, not a list that should be immediately unpublished. From here on, I will explain how much evidence can be obtained with list filters, and how to supplement the parts that the screen alone cannot cover.