ServiceNow / Service Catalog / Human in the loop
ServiceNow Device and Software Request Approvals
I built a ServiceNow catalog workflow for device and software requests in the Global application scope. Access is limited to designated groups. A request captures the operating system, RAM, storage, and software packages, then follows two sequential human approval gates: one member of the designated approval group, followed by the manager of the person who opened the request (Opened by → Manager).
This project covers catalog configuration and approval orchestration. Approval makes a request eligible for fulfillment; it does not demonstrate automatic device provisioning or software installation.
Explore the approval workflow
Configure an example request, then try approval and rejection at each gate. Manager approval becomes available only after group approval.
- 1Catalog request
- 2One group member
- 3Opened by → Manager
- 4Request outcome
- Operating system
- Windows
- RAM
- 16 GB
- Storage
- 512 GB
- Software packages
- GitHub CLI
Configure a request
Configure an example request, then try approval and rejection at each gate. Manager approval becomes available only after group approval.
Illustrative browser demo with example configuration values. No request is sent to ServiceNow. Compatibility filtering here is a demonstration, not a claim about the live catalog.
1. A catalog for the intended audience
The catalog is available to designated groups rather than to every employee. It is configured in the Global application scope. Application scope and catalog visibility serve different purposes: Global does not mean that every user can see or request the item.
- Group membership determines the intended catalog audience.
- The request presents a defined device and software offering instead of an unstructured free-text ticket.
- Catalog visibility is distinct from access to the underlying records. A production implementation also needs appropriate record permissions.
2. Capture the configuration once
The form collects the operating system, RAM, disk capacity, and applications to install. Windows, macOS, and Linux are the operating-system choices; Photoshop and GitHub CLI are examples of software packages. Reviewers can assess the configuration attached to the same request.
- Operating system defines the requested platform.
- RAM and storage describe the required hardware profile.
- Software packages make the application requirements explicit. Compatibility and licensing checks are useful extensions; the example below illustrates compatibility filtering without claiming it is already implemented in ServiceNow.
3. First gate: one approval from the group
The first human approval belongs to the designated approval group. One member approving is sufficient for this gate; the requester does not need every member to approve. While the decision is pending, the manager stage has not started.
- Submitted request → wait for a group decision.
- One group member approves → proceed to manager approval.
- The group gate rejects → stop the approval path and mark the request incomplete.
4. Second gate: manager approval
Manager approval is requested only after the first gate succeeds. The approver is the manager of the person identified by Opened by: Opened by → Manager. This keeps the decisions sequential and gives that manager the device and software configuration already reviewed by the group.
- Group approval is a prerequisite for the manager stage.
- Manager approval → the request is ready to proceed to fulfillment.
- Manager rejection → the example follows the same incomplete outcome. Missing manager assignments and unanswered approvals should be handled explicitly before a production rollout.
5. Keep approval and fulfillment distinct
An approved request is authorized to proceed. A rejected request remains incomplete. Neither outcome is evidence that a workstation has been created, a license assigned, or software installed. Separating these responsibilities makes the workflow easier to explain and extend.
- Completed approval: both required gates accepted the request.
- Incomplete request: an approval gate rejected it.
- Future fulfillment integrations could create service tasks or invoke endpoint-management tooling after approval. Those integrations are potential applications of the design, not delivered features of this project.
What problems does this solve?
Device and software requests often require repeated questions, unclear ownership, and manual approval handoffs. A structured catalog records the requirements once and makes the next decision visible.
- Consistent requests: reviewers receive the OS, hardware requirements, and software choices together.
- Clear ownership: group review and manager authorization have separate, ordered responsibilities.
- Controlled progression: an incomplete or rejected approval cannot be presented as authorization for fulfillment.
- Reusable pattern: the same approval structure can support equipment, software access, or other service requests with their own rules.