Service Catalog Retirement: Close Every Intake Path

A team removes “Prepare a custom weekly report” from its service catalog. The old form still works from a bookmark, a scheduled email keeps generating requests, and two reports already promised to colleagues have no continuing owner. The menu changed; the service did not finish retiring.

A service catalog retirement workflow manages the permanent withdrawal of an offered request type. Its work object is one retirement case tied to the exact offering and scope. Its outcome is a closed admission route, accounted-for commitments and an accepted end to residual delivery—not simply an unpublished catalog tile.

This blueprint is for internal shared-services operations. It extends the internal service catalog design model into an end-of-life operation. It is not a technical infrastructure shutdown guide, a records-disposal policy or authority to cancel contractual obligations.

Define what is ending—and what is not

Identify the service outcome, eligible requesters, affected catalog identifiers and delivery team. State whether the offering ends completely, moves to a replacement or stops for a defined population. Renaming the item or replacing its instructions is not necessarily retirement if people can still obtain the same service through the old route.

There are useful precedents for treating retirement as a transition. NC State’s service-offering retirement guidance separates work in a Retiring status from final retirement and includes reviewing the offering’s portal, request-item and knowledge presence. That is its institutional process, not a universal requirement.

Keep the retirement case separate from individual service requests. The case controls whether the offering may accept demand and when support can end. Each earlier request retains its own delivery status, owner and evidence. Likewise, withdrawing an obsolete SOP changes current instructions; it does not by itself end a service promise.

Set two boundaries instead of one retirement date

Boundary one: stop accepting new demand

Record a cutoff date, time, time zone and authoritative event. For example, the service owner may define acceptance as a request successfully recorded in the designated system before the cutoff. A draft saved on someone’s laptop or an email sent before the deadline may require different treatment; decide that explicitly rather than arguing after the event.

Include returned-for-correction requests, repeat submissions and requests already received but not yet registered. Define a review route for disputed timestamps. Preserve the actual receipt and acceptance evidence; do not alter timestamps to make a request qualify.

Boundary two: end residual delivery

Set the conditions for finishing earlier commitments and releasing the old service’s delivery responsibilities. A request accepted before the cutoff may still need work afterward. Staff and dependencies needed for that work must remain available until delivery finishes or another authorized owner accepts the obligation.

The service owner recommends these boundaries. The designated business approver authorizes them under local governance. The retirement coordinator maintains the case, channel owners change admission routes, delivery owners resolve commitments, and a named verifier checks the actual results. If one person fills several roles, record the separate decisions rather than treating a completed task as every approval.

Use a state model with explicit release gates

Start when a service owner proposes permanent withdrawal. Intake should capture the reason, exact offering IDs, scope, approver, coordinator, proposed boundaries, replacement or no-replacement rationale, known channels, open commitments, dependencies and evidence location. Missing scope or authority stays in review with a named clarification owner.

A rejected proposal closes with its reason and a continuing service owner. A failed gate does not advance because the planned date passed. Keep the current state, blocked reason, accountable exception owner and next review time visible.

Use the organization’s change control process to authorize implementation where applicable. Service Manager’s catalog-item retirement guidance, for example, assigns the retirement plan to the catalog owner and puts its implementation through change management. Follow the supported controls for your actual system, not another product’s button sequence.

Close admission across the routes people actually use

Build one channel register for the offering. Ask delivery staff and requesters how work reaches them, then compare that account with forms, routing rules and recent request sources. A catalog search alone cannot establish that every entry point has been found.

For each route, retain its identifier or location, owner, approved treatment, test result, observation time and evidence reference. Mark a route not applicable only after checking why it cannot generate demand for this offering.

Use approved test data and procedures; do not create real customer commitments just to prove a route works. A technical acknowledgement is not proof of the intended business disposition. Inspect the resulting record or rejection through the system’s supported controls.

Do not assume “hidden” means “cannot be submitted.” Microsoft’s Service Manager catalog documentation describes Draft request offerings as unavailable for end-user requests in that product. It does not establish how your platform handles bookmarked forms, integrations or staff-created records. Verify each applicable route.

Drain commitments without cancelling them by implication

Take a dated inventory of work already accepted, including linked fulfillment tasks and commitments held outside the main queue. Refresh it around the cutoff so work arriving during implementation is not omitted. Preserve original request IDs, age, approvals and service targets.

Give each commitment one controlling disposition and the evidence that makes it valid:

• Finish under the old service: keep a delivery owner, due date, required evidence and access to dependencies until completion is accepted.
• Transfer to a replacement: record the receiving service and owner, eligibility, evidence and accepted next action. Do not treat a forwarded message as acceptance or count an open handoff as completed.
• Withdraw or cancel: require the appropriate authority and resolve already-performed work and downstream effects through the relevant process. Catalog retirement alone supplies no cancellation authority.
• Hold for a decision: assign a decision owner, reason, next action and review time. This is an unresolved commitment, not a retirement-complete category.

For transferred work, distinguish a plan from an accepted transfer. The sender is the current delivery owner; the completion condition is an authorized treatment with a complete request packet. Send the original identity, agreed outcome, evidence, deadlines, dependencies and outstanding decisions. The receiver accepts only after confirming responsibility, access and a feasible next action. Until then, the sender retains ownership.

If changing the underlying workflow definition is necessary, handle that through a separate in-flight workflow migration decision. Do not restart a request to erase its age or make previous approvals appear to cover different work.

Give late demand and failed checks a recovery path

A route still accepts requests after the cutoff

The channel owner records the source and actual acceptance time, contains further intake through supported controls and checks the affected population. The service owner decides how accepted late work will be treated; do not delete it or label it spam to make the retirement totals balance. Keep the case blocked until the route is corrected and retested and the leaked commitments are owned.

The replacement rejects a handoff

The current delivery owner retains the item and records the rejection reason. Escalate to the service owner for corrected eligibility, an accepted alternative or a revised boundary. Resume transfer only after the receiver accepts the actual packet. If replacement readiness was a retirement condition, the retirement case cannot close while it is unresolved.

An owner, dependency or result is unavailable

The coordinator escalates an unaccepted assignment to the responsible team lead for a named backup. A delivery owner must confirm any supplier or other external dependency required to finish residual work; do not release it merely because the catalog item is gone. An uncertain configuration response stays unverified until the channel owner reads back the actual state and test result before repeating the change.

Instructions conflict or an exception becomes overdue

Link duplicate retirement proposals to one controlling case for the same offering and scope. The designated approver resolves conflicting dates or exceptions. A late-demand exception needs an exact population, authorizer, delivery owner and end condition; it must not quietly reopen unlimited intake. Escalate overdue exceptions at their agreed review point, and resume the gate only with current evidence and an authorized decision.

Reconcile a report-service retirement

Illustrative example: an operations team ends its custom weekly-report request offering after a self-service option becomes available. The owner sets Friday at 17:00 in the team’s time zone as the new-request cutoff. Earlier commitments can finish through the following reporting cycle; that is a separate delivery boundary.

The opening register contains eight accepted reports. Five finish under the old service, two are accepted by the replacement team’s owner with their original references, and one receives an authorized cancellation after its downstream work is checked. At that point, eight original commitments have completed dispositions; a hold or merely proposed transfer would not qualify.

The catalog tile and bookmarked form pass their checks, but the next scheduled email still generates a ninth request after the cutoff. The coordinator logs the leakage rather than changing the opening population. The service owner records an explicitly bounded exception with a delivery owner. The channel owner corrects the recurring source and supplies retest evidence.

The retirement stays open until the ninth request reaches its authorized disposition, channel checks pass and required delivery dependencies can be released. The final record distinguishes eight opening commitments, one late acceptance and each verified result. The count reconciles without implying that a removed menu item completed the work.

Measure the remaining exposure

• Demand: new retirement proposals and attempted demand for the offering after cutoff, separated from actually accepted requests.
• Flow: time from authorization to verified intake closure, and from intake closure to final retirement.
• Queue health: oldest unresolved commitment, unaccepted transfer and blocked channel check by owner.
• Quality and reliability: post-cutoff acceptances by source, failed retests and commitments incorrectly reported as resolved.
• Capacity: residual delivery and verification workload against the staff and dependencies retained for it.
• Outcome: opening commitments plus later accepted work, reconciled to completed delivery, accepted transfer, authorized cancellation and still-unresolved items.

State the inventory’s boundary. All known channels passing is useful evidence, not proof that no undiscovered entry point exists. Agree a risk-based follow-up period and owner for late findings. If a retired route is discovered later, open a linked corrective action and assess affected work; do not silently reopen the offering or erase the original retirement history.

Where Workhint fits

The Workhint Workflow Engine describes request steps, role-directed approvals and required details, files or notes before work moves forward. Those building blocks are relevant to collecting a retirement proposal and requiring evidence before a release decision.

Workhint’s Workflow Automation Software solution describes structured forms, process stages, roles, conditional routing, tasks and event-based notifications. This is a relevant basis for coordinating channel owners, commitment reviews and verification tasks around an internal service offering.

Neither page establishes automatic discovery or disabling of every external intake route, native migration of existing commitments, technical decommissioning or immutable audit records. Identify which system controls each route and who returns its evidence. Keep any unsupported control behind an explicit manual gate rather than treating a case status as proof it happened elsewhere.

Build This in Workhint

Use this configuration brief as a design to validate, not a claim that every control is available automatically:

Coordinate retirement of [internal service offering]. Outcome: new admission routes are verified closed and existing commitments have accepted dispositions. Define service-owner, approver, coordinator, channel-owner, delivery-owner and verifier roles. Limit approval authority and evidence access to their assigned scope.

Capture offering IDs, reason, scope, replacement, two effective boundaries, channel register, commitment register, dependencies and decisions. Track Proposed, Impact review, Authorized, Intake closing, Draining commitments, Verification pending and Retired. Require current channel tests, accepted handoffs and commitment reconciliation before closure.

Assign implementation, delivery, retest and exception tasks; notify owners at meaningful changes and agreed review points. Block missing authority, invalid evidence, unavailable owners, failed intake tests, rejected transfers, duplicate instructions and unknown external outcomes with a named escalation and resume condition. Provide channel, residual-work, late-demand and overdue-exception views with the measures above. Retain actors, timestamps, decisions and evidence references; validate audit-history, access and retention behavior. Treat external route changes and any concurrency controls as requirements to prove separately.

FAQ

Is unpublishing the catalog item enough?

Not without checking the applicable entry points and existing commitments. Catalog discovery, direct submission and delivery ownership may be separate controls. Verify the behavior of the actual systems you use.

Do all open requests have to move to the replacement?

No. Decide whether each request should finish under the old service, transfer with acceptance or receive another authorized disposition. Preserve the original identity and record why that treatment is valid.

Can a service retire without a replacement?

Yes, when the authorized decision ends the offering and resolves its remaining commitments and dependencies. Make the no-replacement outcome and requester guidance explicit rather than implying that another team will absorb the work.

When can the retirement case close?

When the approved admission and delivery conditions pass, the verifier’s evidence is accepted and no unresolved obligations remain without an accepted transfer or other authorized resolution. Passing a planned date or completing an administrative action is not enough.