Service Catalog and Incident Management both accept user demand, but they model different outcomes. A catalog request asks the organization to provide something through a defined fulfillment path. An incident asks the organization to restore normal service after an interruption or degradation. Treating those records as interchangeable may seem convenient at the portal, but it weakens assignment, automation, service-level reporting, and the history teams need when demand changes from \u201cgive me something\u201d to \u201csomething is broken.\u201d<\/p>\n
For ServiceNow CIS-ITSM<\/a>, the important distinction is not which form a user happens to open. It is the intent of the work. A new laptop, access entitlement, software installation, standard account change, or other predefined deliverable usually belongs in Request Management. A failed application, unavailable VPN, broken integration, or degraded service belongs in Incident Management. The platform can link the two when the same real-world situation needs both processes.<\/p>\n ServiceNow Service Catalog is designed around catalog items that represent products or services a user can request. A catalog item can collect variables, apply eligibility criteria, obtain approvals, launch flows, create fulfillment tasks, and expose a predictable status to the requester. Current ServiceNow Request Management architecture starts when a catalog item is requested and creates a hierarchy centered on the Request, Requested Item, and Catalog Task records.<\/p>\n The Requested Item, commonly called a RITM, is usually the most useful operational level because it represents one requested catalog item and carries its variables. Catalog tasks can divide fulfillment into work owned by different groups. A single request can therefore coordinate several activities without forcing every fulfillment team to work from the same generic ticket.<\/p>\n This structure is valuable when the organization wants a controlled service-delivery pattern. The catalog can make the user choose a laptop model, cost center, software package, requested-for user, or entitlement level before fulfillment begins. Approvals and routing can be derived from those selections. The request becomes measurable work rather than an unstructured description sent to a queue.<\/p>\n That also explains why ServiceNow CSA<\/a> concepts matter to request design. Catalog administration is not only a front-end form exercise. Variables, user criteria, flow behavior, task generation, permissions, notifications, and data relationships determine whether the fulfillment process remains supportable after the first successful demo.<\/p>\n An incident represents an unplanned interruption, reduction in service quality, or another condition that requires restoration. The immediate outcome is operational: get the affected service back to an acceptable state while managing business impact. Investigation can continue, but restoration should not be delayed simply because a permanent fix or full root cause is not yet available.<\/p>\n Incident data therefore emphasizes impact, urgency, priority, assignment, affected service or configuration item, symptoms, diagnostics, work notes, resolution, and related operational records. A useful incident record tells responders what is failing, who is affected, what has already been tried, and what restored service.<\/p>\n That purpose is fundamentally different from a request such as \u201cprovision Adobe Acrobat for a new employee.\u201d The software request may take hours or days because approvals and licensing are part of normal fulfillment. If Adobe Acrobat was already provided and now fails to launch for a user, the organization is restoring an existing service capability, so an incident is a better model.<\/p>\n Classification cannot be based only on nouns such as laptop, email, VPN, database, or access. The same object can appear in both processes. \u201cGive a contractor VPN access\u201d is a request. \u201cMy approved VPN access stopped working this morning\u201d is an incident. \u201cProvision a database for a new project\u201d is a request. \u201cThe production database is refusing connections\u201d is an incident.<\/p>\n A good portal experience makes that difference understandable without expecting users to know ITIL vocabulary. Request experiences can be organized around things people need, while incident experiences can be organized around getting help with something that is not working. Behind the portal, the records should still land in the process whose lifecycle matches the work.<\/p>\n This matters because routing by keyword is fragile. If \u201caccess\u201d always creates an incident, routine entitlement requests fill support queues. If \u201claptop\u201d always creates a catalog request, a failed device that needs urgent restoration can disappear into a normal fulfillment backlog. The decision should follow intent and outcome.<\/p>\n Current ServiceNow documentation explicitly supports creating a catalog request from an incident in Agent Workspace and associating the two records. That is useful because restoration often reveals a need for a standard deliverable. An analyst may discover that a user\u2019s old device must be replaced, a standard software package must be provisioned, or an approved access change is required.<\/p>\n The incident can continue to own the restoration story while the catalog request owns fulfillment. The incident might document a temporary workaround that allows the user to continue working. The RITM can then move through approvals, inventory allocation, shipping, installation, or other tasks that are normal for the requested item.<\/p>\n Keeping both records preserves accurate metrics. The incident\u2019s restoration clock should not stay open for three days merely because a standard hardware request is waiting for delivery. Conversely, a request should not be marked complete simply because the incident was restored with a temporary workaround if the requested item still has to be provided.<\/p>\n A mature catalog reduces ambiguity by turning common demand into repeatable choices. If every request for a virtual machine arrives as free text, fulfillment teams must repeatedly ask for environment, size, network, owner, data classification, expiration, and cost information. A well-designed catalog item captures those values up front and can drive downstream automation.<\/p>\n But not every request should become a giant catalog item with dozens of branching variables. Catalog design should reflect real fulfillment decisions. A variable is valuable when it changes approval, routing, configuration, fulfillment work, cost, or another meaningful outcome. Fields that exist only because someone might someday report on them often create friction without improving delivery.<\/p>\n The same principle applies to incident forms. Do not force request-style procurement detail into an incident if responders only need enough information to diagnose and restore service. Record design should support the process, not turn every ticket into the same universal questionnaire.<\/p>\n Catalog flows can be designed around deterministic stages such as approval, fulfillment, validation, and completion. A RITM can create catalog tasks for identity, endpoint, infrastructure, or application teams and wait for those tasks to finish before closing. Variables can provide structured inputs to each task or integration.<\/p>\n Incident automation is usually centered on triage and restoration: assignment rules, priority logic, major-incident criteria, notifications, diagnostics, knowledge suggestions, escalations, and resolution controls. Automating an incident as though it were a request can bury urgent work behind approvals that make sense for normal provisioning but not for restoration.<\/p>\n Automating a request as though it were an incident creates the opposite problem. The ticket may be closed once someone gives a quick response even though fulfillment still requires approvals or downstream work. The data model then stops representing the actual lifecycle.<\/p>\nService Catalog models repeatable demand and fulfillment<\/h2>\n
Incident Management models restoration after disruption<\/h2>\n
The same subject can produce either a request or an incident<\/h2>\n
A request can be created from an incident without becoming the incident<\/h2>\n
Use request design to standardize fulfillment, not to hide exceptions<\/h2>\n
Automation behaves differently when the process is modeled correctly<\/h2>\n