Catalog Fulfillment Pipeline Pattern in…

intermediateTested on Xanadu

The Catalog Fulfillment Pipeline Pattern establishes a standardized, repeatable workflow for processing catalog requests from initial submission through final closure. This pattern creates a structured approach to handling approvals, task generation, fulfillment group routing, and automated closure conditions across all catalog items in your ServiceNow instance.

This pattern solves the common problem of inconsistent catalog fulfillment processes where different teams handle requests differently, leading to confusion, delays, and poor user experience. By implementing a unified pipeline, organizations can ensure predictable processing times, clear accountability, and consistent service delivery regardless of which catalog item is requested.

The pattern works by defining stages in the fulfillment lifecycle, each with specific entry criteria, processing logic, and exit conditions. Approval stages route requests to appropriate stakeholders, catalog task templates ensure consistent work assignments, fulfillment groups receive properly categorized work, and automated closure rules eliminate manual overhead while maintaining audit trails.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Use This When

Use this pattern when you have multiple catalog items with varying fulfillment requirements that need standardization, or when you're experiencing inconsistent processing times and unclear accountability in your current catalog workflows. This pattern is ideal for organizations with mature ITSM processes that need to scale catalog operations efficiently.

Avoid When

Avoid this pattern if you have very simple catalog items with straightforward, single-step fulfillment processes, or if your organization prefers highly customized, item-specific workflows. The overhead of maintaining pipeline stages may not justify the benefits for small organizations with limited catalog complexity.

Implementation

Server-side

var CatalogFulfillmentPipeline = Class.create();
CatalogFulfillmentPipeline.prototype = {
    initialize: function() {
        this.STAGE_SUBMITTED = 'submitted';
        this.STAGE_APPROVAL = 'approval';
        this.STAGE_FULFILLMENT = 'fulfillment';
        this.STAGE_COMPLETED = 'completed';
    },

    processRequest: function(requestSysId) {
        var gr = new GlideRecord('sc_request');
        if (!gr.get(requestSysId)) {
            gs.error('Request not found: ' + requestSysId);
            return false;
        }

        var currentStage = gr.getValue('stage') || this.STAGE_SUBMITTED;
        gs.info('Processing request ' + requestSysId + ' in stage: ' + currentStage);

        switch (currentStage) {
            case this.STAGE_SUBMITTED:
                return this._processSubmitted(gr);
            case this.STAGE_APPROVAL:
                return this._processApproval(gr);
            case this.STAGE_FULFILLMENT:
                return this._processFulfillment(gr);
            default:
                return false;
        }
    },

    _processSubmitted: function(requestGR) {
        // Determine if approval is required based on catalog item configuration
        var itemGR = new GlideRecord('sc_cat_item');
        var reqItemGR = new GlideRecord('sc_req_item');
        reqItemGR.addQuery('request', requestGR.getUniqueValue());
        reqItemGR.query();

        var needsApproval = false;
        while (reqItemGR.next()) {
            if (reqItemGR.cat_item.approval_required == true) {
                needsApproval = true;
                this._createApprovalRecord(reqItemGR);
            }
        }

        if (needsApproval) {
            requestGR.setValue('stage', this.STAGE_APPROVAL);
            requestGR.setValue('state', 'pending_approval');
        } else {
            requestGR.setValue('stage', this.STAGE_FULFILLMENT);
            this._createFulfillmentTasks(requestGR);
        }
        requestGR.update();
        return true;
    },

    _processApproval: function(requestGR) {
        var approvalGR = new GlideRecord('sysapproval_approver');
        approvalGR.addQuery('sysapproval', requestGR.getUniqueValue());
        approvalGR.addQuery('state', 'requested');
        approvalGR.query();

        if (approvalGR.getRowCount() == 0) {
            // All approvals complete, check for rejections
            approvalGR = new GlideRecord('sysapproval_approver');
            approvalGR.addQuery('sysapproval', requestGR.getUniqueValue());
            approvalGR.addQuery('state', 'rejected');
            approvalGR.query();

            if (approvalGR.getRowCount() > 0) {
                requestGR.setValue('stage', this.STAGE_COMPLETED);
                requestGR.setValue('state', 'closed_rejected');
            } else {
                requestGR.setValue('stage', this.STAGE_FULFILLMENT);
                requestGR.setValue('state', 'fulfillment');
                this._createFulfillmentTasks(requestGR);
            }
            requestGR.update();
        }
        return true;
    },

    _processFulfillment: function(requestGR) {
        var taskGR = new GlideRecord('sc_task');
        taskGR.addQuery('request', requestGR.getUniqueValue());
        taskGR.addQuery('state', 'IN', '1,2,3'); // Open, Work in Progress, Pending
        taskGR.query();

        if (taskGR.getRowCount() == 0) {
            // All tasks complete, check for closure conditions
            if (this._validateClosureConditions(requestGR)) {
                requestGR.setValue('stage', this.STAGE_COMPLETED);
                requestGR.setValue('state', 'closed_complete');
                requestGR.setValue('closed_at', new GlideDateTime());
                requestGR.update();
                gs.info('Request ' + requestGR.getUniqueValue() + ' automatically closed');
            }
        }
        return true;
    },

    _createApprovalRecord: function(reqItemGR) {
        var approval = new GlideRecord('sysapproval_approver');
        approval.initialize();
        approval.setValue('sysapproval', reqItemGR.request.toString());
        approval.setValue('approver', reqItemGR.cat_item.approval_group.toString());
        approval.setValue('state', 'requested');
        approval.insert();
    },

    _createFulfillmentTasks: function(requestGR) {
        var reqItemGR = new GlideRecord('sc_req_item');
        reqItemGR.addQuery('request', requestGR.getUniqueValue());
        reqItemGR.query();

        while (reqItemGR.next()) {
            var taskGR = new GlideRecord('sc_task');
            taskGR.initialize();
            taskGR.setValue('request', requestGR.getUniqueValue());
            taskGR.setValue('request_item', reqItemGR.getUniqueValue());
            taskGR.setValue('short_description', 'Fulfill: ' + reqItemGR.getDisplayValue('cat_item'));
            taskGR.setValue('assignment_group', reqItemGR.cat_item.fulfillment_group.toString());
            taskGR.setValue('state', '1'); // Open
            taskGR.insert();
        }
    },

    _validateClosureConditions: function(requestGR) {
        // Check that all request items are fulfilled
        var reqItemGR = new GlideRecord('sc_req_item');
        reqItemGR.addQuery('request', requestGR.getUniqueValue());
        reqItemGR.addQuery('state', '!=', '3'); // Not closed complete
        reqItemGR.query();
        
        return reqItemGR.getRowCount() == 0;
    },

    type: 'CatalogFulfillmentPipeline'
};

This Script Include implements a state machine pattern that processes catalog requests through defined stages with specific business logic at each transition. The processRequest method serves as the main entry point, routing requests to appropriate stage handlers based on current state. Key features include automatic approval creation based on catalog item configuration, dynamic task generation with proper assignment group routing, and closure validation that ensures all request items are complete before final closure.

Alternatives

Workflow-Based Fulfillment

Use ServiceNow Workflow or Flow Designer to model the fulfillment process visually with drag-and-drop stages. This approach is more accessible to non-developers but can become complex to maintain and debug with sophisticated routing logic.

Event-Driven Pipeline

Implement the pipeline using business rules and events that fire at each stage transition, providing loose coupling between stages. This approach offers better performance and scalability but requires more careful event management and can be harder to trace end-to-end flow.

Catalog Item-Specific Scripts

Create individual fulfillment scripts for each catalog item or category, allowing maximum customization per item type. This approach provides the most flexibility but creates maintenance overhead and inconsistent user experiences across different catalog items.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue