OBLYTECH Logo
OBLYTECH Logo
ServiceNow Request Fulfilment and Service Catalog Use Cases for Enterprise Teams
Home / Guides, Services and Solutions / IT Service Management: Guides and Services / Request Fulfilment and Service Catalog: Guides and Services / ServiceNow Request Fulfilment and Service Catalog Use Cases for Enterprise Teams

ServiceNow Request Fulfilment and Service Catalog Use Cases for Enterprise Teams

Request fulfilment is the stage where an approved catalog request becomes a delivered service, and the service catalog is the front door that starts it. This page sets out enterprise use cases, the prerequisites each one needs and how to choose the first items to build.

Use Case 1: Self-Service Password Reset for End Users

End users can reset their own passwords without contacting the service desk. A service catalog item allows users to enter their username or email, verify their identity through security questions or alternative authentication, and reset their password automatically. The system confirms the reset via email and logs the action for audit purposes.

Benefit: This self-service capability reduces password reset tickets significantly, freeing service desk staff to focus on more complex issues. Users get immediate resolution rather than waiting for service desk availability.

Prerequisites: A system integration that can authenticate users and change their password in the directory service. A workflow that verifies user identity before allowing password reset. Clear communication to users about how to use this feature.

Use Case 2: IT Hardware and Software Procurement

Employees request new laptops, monitors, software licenses or peripherals via the service catalog. Requests include details about intended use, software requirements and delivery location. Approvals route through the requester’s manager and the IT procurement team. Approved requests trigger orders with vendors and automatically update asset management records when hardware arrives.

Benefit: Automated procurements reduce administrative work, provide visibility into pending hardware orders and automatically track assets as they are acquired. Managers have visibility into what their team is requesting, and procurement teams receive structured requests with all necessary information upfront.

Prerequisites: Integration with procurement systems or vendors. Defined approval rules based on request cost or requester role. Automation to update asset management when hardware is received and deployed.

Use Case 3: Access Request Management

Employees request access to applications, systems or data repositories. The request includes information about the resource being requested, the business justification and the expected duration of access. The request routes through the requester’s manager for approval and then to the resource owner for final approval. Once approved, access is automatically provisioned through identity management integrations. When access expires, it is automatically revoked.

Benefit: Structured access requests provide audit trails for compliance. Automation reduces manual provisioning and deprovisioning errors. Resource owners have visibility into who has access to their systems and why, supporting least-privilege security practices.

Prerequisites: Integration with identity management or directory services for access provisioning. Defined approval workflows. Clear ownership of resources and access policies.

Use Case 4: Facilities and Real Estate Requests

Employees request office space, conference room bookings, parking spaces or furniture. Requests route through workspace management systems that check availability and confirm the booking. Approved requests generate work orders for facilities teams to prepare the space or deliver furniture. Requests flow to operations for cost tracking and billing.

Benefit: Self-service facilities requests eliminate phone calls and email coordination. Automated availability checking prevents double-booking. Facilities teams receive structured requests with all required information and can prioritize based on request urgency.

Prerequisites: Integration with facilities management systems. Real-time availability checking. Workflows that route to the appropriate facilities team.

Use Case 5: HR Service Requests and Employee Onboarding

New employees submit requests for benefits enrollment, equipment setup and orientation scheduling. Existing employees request payroll changes, time off or training. HR team members route requests to appropriate processors (benefits administrator, payroll specialist, trainer). Integrations trigger relevant background systems (payroll, benefits, learning management) to execute the requested action.

Benefit: Centralized request management provides visibility into HR work. Automation routes requests to qualified handlers and triggers background systems, reducing manual data entry and errors. New employees can self-service basic onboarding items.

Prerequisites: Integration with payroll, benefits and learning management systems. Clear ownership of different HR functions. Approval workflows aligned with HR governance.

Use Case 6: Quality Assurance and Testing Environment Provisioning

Development teams request test environments (databases, application instances, test data) for feature development or testing. Requests include environment specifications (operating system, memory, database size) and the intended testing duration. Infrastructure teams review requests for feasibility and cost and approve or suggest alternatives. Approved requests automatically provision infrastructure using infrastructure-as-code tools. When the testing period ends, infrastructure is automatically deprovisioned.

Benefit: Automation accelerates environment provisioning, reducing development cycle time. Cost tracking helps teams understand infrastructure spending. Automatic deprovisioning ensures environments are not left running unnecessarily, reducing waste.

Prerequisites: Infrastructure-as-code capabilities or virtualization platforms that support automated provisioning. Integration between ServiceNow and infrastructure platforms. Clear policies around environment sizing and lifecycle.

Use Case 7: Budget and Financial Approval Workflows

Expense reports, purchase requests and travel approval requests flow through ServiceNow with approvals based on cost thresholds and requester role. A modest expense (under budget authority) is auto-approved. A larger expense requires manager and finance approval. Approved requests flow to the accounting system for processing. Audit trails capture all approvals and rejections.

Benefit: Structured workflows ensure appropriate oversight while not slowing routine requests. Audit trails support compliance with financial controls. Accounting systems receive approved requests in structured format, reducing manual entry errors.

Prerequisites: Clear definition of approval authorities based on cost and requester role. Integration with accounting and travel booking systems. Audit trails for all approvals.

Use Case 8: Vendor Onboarding and Contract Management

Procurement teams use ServiceNow to manage vendor onboarding workflows. A new vendor must be approved by legal (contract review), security (vendor assessment) and finance (payment terms negotiation). Once all approvals are complete, the vendor is activated in the procurement system. Integration maintains vendor records in accounting and purchasing systems.

Benefit: Structured vendor onboarding ensures all compliance checks are completed before engaging a vendor. Audit trails document who approved each vendor and when. Vendor information is consistently available across systems.

Prerequisites: Integration with legal contract management and vendor assessment platforms. Finance system integration for payment terms and vendor master data.

Implementing Request Fulfillment and Service Catalog Successfully

Across all these use cases, success depends on clear request design, efficient routing through approvals and integration with backend systems that actually fulfill requests. Organizations that automate these patterns see significant reduction in manual work, improved compliance with governance policies and faster service delivery to end users.

Choosing the first catalog item from a long wish list

Every department can name a request it would like in the catalog, and the wish list grows faster than the team that has to build and maintain the items. The first release is not the place to build everything. It should contain the few requests that are frequent, predictable and owned by a single fulfillment team, because those are the items where automation pays back quickly and where a mistake is easy to see and fix.

The question to ask of each candidate is not whether it sounds useful. Ask how often it happens, how much the requests differ from one another, how many people must approve them and whether the work depends on a system that cannot yet be reached from the platform.

A scoring grid for shortlisting candidates

Candidate request Volume Variation between requests Approval steps Fit for a first release
Standard peripheral or consumable request High Low, a handful of options One manager Strong
Access to a shared system with a named owner Medium Medium, depends on role Manager and resource owner Good once the role mapping exists
Test environment build Medium High, sizing differs each time Infrastructure review Later, after the sizing rules are agreed
Commercial terms for a new supplier Low Very high Legal and finance negotiation Not a catalog item at all

Scores are only a conversation starter. A candidate with high volume and low variation can still be a poor first choice if its fulfillment team has no spare capacity to watch the new queue during the first weeks.

Steps for narrowing the list to one or two items

  1. Count the requests of each type over a recent period, using whatever record exists: service desk tickets, email folders or call notes. Rough counts are enough for the first pass.
  2. Mark how many of those requests were follow-up questions, such as asking where a form is or whether an approval has moved. Items with many follow-ups usually have a design problem the catalog would inherit.
  3. For each shortlisted item, write down the fields a fulfiller needs to start work. If the list is long or contains free text that nobody can validate, the item needs redesign before it is built.
  4. Check whether the fulfillment work can be started from the platform, or whether it depends on a manual step in another system. Manual steps are not disqualifying, but they must be named and owned.
  5. Choose the candidate with one fulfillment team, one approval route and the clearest definition of done. Build that before adding a second item.

When a catalog item is the wrong answer

Some requests look like catalog material and are not. A one-off project that needs scoping, a negotiation over commercial terms and a request to restore a service that has failed all belong to other processes. Forcing them into a form creates an item that is used once, rarely finishes and gives requesters the false impression that their situation fits a template.

  • A request whose correct answer depends on a conversation rather than a choice from a fixed set of options.
  • A request that reports a fault. Requests of that kind belong in incident management, where the priority and the impact can be judged.
  • A request the fulfillment team cannot commit to completing within a time they can defend, because the work depends on people outside the team.
  • A request type that changes so often that the item would need rewriting each quarter.

In each case, the better outcome is usually a clear route to the right process, with the requester told which process it is and why, rather than an item that accepts the request and then stalls.

Questions to answer before adding the second item

How many items belong in a first release?

Few enough that the team can test each one against the risk tiers, watch its queue for the first weeks and retire it cleanly if it fails. A first release that is too large usually ships with its weakest items unexamined.

Can we copy a use case that worked for another organization?

You can borrow the shape of the request, but not the approval rules, the fulfillment groups or the data it assumes. Those belong to your organization, and a copied item that refers to roles you do not have will fail quietly.

Who owns the list of candidates after the first release?

The catalog manager should own it, with each service owner proposing additions. Keep the list in one place with a status, a sponsor and a date for each candidate, so that a request for a new item can be compared with what is already waiting.

What if a candidate looks like an incident every time?

Then it probably is one, or it is a symptom of a missing standard service. The incident management library covers how to separate faults from requests, and that separation is worth settling before any item is built.

The guidance on catalog request eligibility and the procurement request workflow controls article are useful next reads when the shortlist includes purchasing.

Frequently asked questions

What if a request cannot be fulfilled automatically and requires human intervention?

Route the request to the appropriate fulfillment team via workflow. The team receives a structured request with all information upfront and can fulfill manually if automation is not available. Track manual fulfillment time and use it to identify candidates for future automation: if a fulfillment step is frequently done manually, it may be worth automating.

How do we handle requests that depend on the completion of other requests?

Use request sequencing or relationships. Document which request must be completed before the next can be fulfilled. For example, a new employee's access request depends on the employee record being created in HR systems. Route requests in the appropriate sequence and notify fulfillment teams when prerequisite requests are complete.

How do we prevent request spam or abuse of the self-service system?

Implement approval workflows for requests that have cost implications. Use rate limiting for common items, at a level the fulfilment team has agreed. for common items. Log all requests and monitor usage patterns to identify unusual activity. Educate users about appropriate use of the service catalog and enforce policies through approvals or usage limits.

Talk to Oblytech

Planning, running or fixing a ServiceNow programme? Tell us where you are and we will suggest a sensible next step.

Contact us