HomeServiceNow Request Fulfillment & Procurement Workflow

Technical source document

ServiceNow Request Fulfillment & Procurement Workflow

Rendered from the retained public repository snapshot. Original wording and result boundaries are preserved.

Original GitHub document All documentation

ServiceNow Request Fulfillment & Procurement Workflow

Status

COMPLETE

The intended request fulfillment and procurement workflow has been performed, validated, evidenced, documented, and accurately bounded. Additional ServiceNow administration work belongs in the separate ServiceNow Administration & ITSM Lab rather than being required for this project's completion.

Objective

Validate a realistic ServiceNow Personal Developer Instance workflow from catalog request through approval, procurement fulfillment, deployment, and automatic request completion.

Technical Areas Demonstrated

  • ServiceNow Service Catalog request handling.
  • Request (REQ), Requested Item (RITM), and Catalog Task (SCTASK) relationships.
  • Approval routing and separation of duties.
  • Assignment groups, users, and fulfillment ownership.
  • Role-qualified assignee troubleshooting.
  • Service Operations Workspace task handling.
  • Work notes and customer-visible comments.
  • Backorder and estimated-delivery tracking.
  • Automatic workflow stage transitions and closure.

Validated Workflow

A Standard Laptop request for Jeremy Fontenot generated REQ0010001 and RITM0010001. The requested item entered approval and was approved by David Loo. ServiceNow then automatically created Procurement task SCTASK0010001.

The Procurement group initially had no usable fulfillment member. A dedicated lab identity, procurement.agent, was created and added to Procurement. Group membership alone did not make the user selectable in Assigned to; inspection of the Task [task].assigned_to dictionary configuration showed a reference qualifier requiring the itil role. Adding the required lab role resolved the invalid-reference condition without weakening the platform qualifier.

Procurement Agent was impersonated to validate the assignee experience. The task was moved to Work in Progress and fulfillment notes were recorded. Because no stock asset was established in the lab, the request was intentionally modeled as a vendor order rather than falsely claiming physical inventory fulfillment. RITM0010001 was marked Backordered with an estimated delivery date, and a customer-visible status update was recorded.

Vendor delivery was then simulated. Backorder status was cleared, procurement completion was documented, and SCTASK0010001 was closed complete. ServiceNow automatically advanced RITM0010001 from Order Fulfillment to Deployment and created Field Services task SCTASK0010002.

A separate field.services.agent lab identity was created, granted the required itil role, and added to Field Services. The deployment task was assigned to that identity and validated through impersonation. Deployment notes were explicitly labeled LAB SIMULATION. The Configuration item field was intentionally left blank because no legitimate CI or physical asset was created.

After SCTASK0010002 was closed complete, ServiceNow automatically changed RITM0010001 to Closed Complete with Stage Completed. The parent REQ0010001 then automatically changed from Open to Closed Complete.

The Request activity recorded:

Request Automatically Closed as all Line Items were complete

Neither the RITM nor the parent REQ was manually forced closed.

Workflow Path

Requester
   |
   v
REQ0010001 / RITM0010001
   |
   v
Approval — David Loo
   |
   v
SCTASK0010001 — Procurement
   |
   +--> Vendor/backorder lab path
   |
   v
Procurement Closed Complete
   |
   v
Automatic RITM transition to Deployment
   |
   v
SCTASK0010002 — Field Services
   |
   v
LAB SIMULATION: endpoint deployment
   |
   v
Field Services Closed Complete
   |
   v
RITM automatically Closed Complete / Completed
   |
   v
REQ automatically Closed Complete

Troubleshooting Finding

The most significant administrative issue was the inability to select the new Procurement fulfillment user in Assigned to. The root cause was not group membership. The Task [task].assigned_to reference qualifier required itil. Granting that role made the user a valid assignee while preserving the existing platform control.

Result

The lab validated the complete relationship between Service Catalog request records, approval, automatically generated fulfillment tasks, assignment groups, role-qualified assignee selection, impersonated fulfillment, vendor/backorder tracking, sequential deployment work, automatic stage progression, and automatic request closure.

Claim Boundary

This is personal-lab work performed in a ServiceNow Personal Developer Instance. Physical laptop procurement, vendor delivery, software installation, and user handoff were simulated. The project demonstrates platform workflow understanding and hands-on administration but does not claim production ServiceNow administration or employer-owned configuration.