ServiceNow Service-Catalog FinOps Design¶

Scope¶

This pattern covers the request-time UX side of FinOps on a ServiceNow service catalog -- the design of the catalog form, T-shirt sizing strategy, cost-presentation timing, finance-approval workflow, and multi-hypervisor catalog structure that together determine whether a VM-request submitter sees a meaningful cost number before they submit and whether finance can credibly approve, allocate, or charge that cost. The cloud-agnostic chargeback fundamentals (showback vs chargeback, 90-95 percent tagging coverage gate, commitment discount strategy, FinOps Foundation Inform/Optimize/Operate framework) live in general/finops.md and general/cost.md and are not repeated here. The back-end VMware-to-ServiceNow cost-data integration (Aria Cost / CloudHealth ingestion, CMDB metadata, allocation engine, ERP journal entries) is covered in patterns/vmware-servicenow-chargeback.md and is treated here as a dependency rather than redefined. The value this file adds is the catalog-form-side design methodology: how many T-shirt sizes, when in the request flow to show cost, which cost factors to include in the request-time display, how to handle multiple hypervisors in a single catalog, and where finance approval slots in. ServiceNow-specific platform constructs referenced here -- Service Catalog, Catalog Items, Record Producers, Order Guides, Service Portal / Now Mobile / Employee Center storefronts, Flow Designer, Variables and Variable Sets, Catalog Client Scripts and UI Policies, Financial Management / Cloud Cost Management -- are documented in providers/servicenow/itsm.md.

Overview¶

A catalog-form FinOps design has to make a decision in five areas, and each area has multiple defensible answers that should be captured as ADRs rather than as defaults:

Cost-presentation timing. Pre-submission (the requester sees an estimate before clicking submit, the form re-prices as they change T-shirt size or environment), post-submission (the ticket is priced after it lands, and the price is what gets routed to finance), or hybrid (a non-authoritative pre-submission estimate plus an authoritative post-submission calculation). Pre-submission requires a per-T-shirt-size price-resolver that can run during form fill; post-submission moves the entire pricing concern into the fulfillment workflow.
T-shirt size discipline. The right cardinality is 5-7 sizes covering 90 percent of requests, with an escape valve for the long tail. Real-world implementations frequently propose 100+ or even 500+ sizes by enumerating every CPU/RAM/disk/network combination; this is the most common single failure mode in catalog FinOps design because it produces a form that nobody can choose from and that bypasses the cost-discipline benefit of having T-shirts in the first place.
Cost-factor scope. Compute, software licensing, backup, network egress, management overhead, and on-prem power/cooling each have their own data sources and refresh cadences. The choice is which subset gets included in the request-time estimate vs which only appears in the monthly chargeback report. Estimates that systematically under-count one or more factors produce user complaints when the chargeback statement arrives and force a credibility-rebuilding cycle.
Finance-approval workflow. Auto-approval threshold, cost-center capture, multi-step routing (cost-center owner -> finance -> provisioning), aging SLAs, and the out-of-band fast-path for time-critical requests. Finance approval inserted at the wrong point in the flow either delays provisioning unnecessarily or routes uncosted requests for approval, defeating both goals.
Multi-hypervisor catalog structure. When the catalog covers Azure plus VMware plus Nutanix (or any subset of multiple back-ends), the choice is between an Order Guide that branches into hypervisor-specific catalog items, a single catalog item that branches form variables by hypervisor selection, or per-hypervisor catalog items the user navigates to directly. Each option distributes complexity differently across catalog UX, fulfillment workflow, and cost-data plumbing.

The catalog-form layer sits on top of the cost-data back end (patterns/vmware-servicenow-chargeback.md) and on top of the cloud-agnostic chargeback model (general/finops.md); designing it in isolation typically produces a form that the back-end pricing layer cannot actually populate, or a form that asks for cost factors that the back end has no way to allocate. The first design step is therefore to confirm which cost factors the back end can produce at request time, what their refresh cadence is, and what the back end will round-trip back to the form.

Checklist¶

Cost-presentation timing¶

[Critical] Is the cost-presentation timing decision -- pre-submission, post-submission, or hybrid -- explicitly made and recorded as an ADR, with the implications for finance-approval routing, form re-pricing behavior, and user expectation-setting documented? (pre-submission gives the requester transparency at form-fill time and lets them confirm cost-center coding before submit, accelerating finance approval downstream; post-submission lets the fulfillment workflow compute an authoritative price using current rate cards but delays cost visibility until after submit; hybrid presents an informational pre-submission estimate while the post-submission calculation is authoritative for budget allocation -- the most common production pattern, but it requires explicit user-facing language that the pre-submission number is an estimate)
[Critical] If pre-submission pricing is chosen, what is the price-resolver mechanism -- a Catalog Client Script reading a rate-card table, a Scripted REST callout to ServiceNow Financial Management / Cloud Cost Management, or a callout to an external FinOps platform (Apptio, CloudHealth, Vantage) -- and what is its latency budget at form-fill time? (catalog forms re-render on each variable change; a price-resolver that takes more than a few hundred milliseconds produces a form that feels sluggish; rate-card lookups against a local ServiceNow table are the fastest path, external callouts add network latency and a failure mode where the form must degrade gracefully if the pricing service is unreachable)
[Recommended] Is the pre-submission estimate explicitly labeled as an estimate, with the basis of estimate (rate card date, FX rate date, included/excluded cost factors) visible to the requester? (an unlabeled "$X per month" implies authority the estimate does not actually have; surfacing the basis of estimate inline -- "Based on rate card as of YYYY-MM-DD, excludes data egress and backup retention" -- reduces dispute volume after the chargeback statement arrives)
[Recommended] Is there a reconciliation step that locks the pre-submission estimate at submission time and compares it against the post-provisioning actual cost on a defined cadence (monthly, quarterly), with variance surfaced to finance? (without reconciliation, estimate accuracy degrades silently as rate cards age and as the catalog accumulates options the back-end pricing does not match; locking the estimate at submission and producing a variance report against actuals is the operational feedback loop that keeps the catalog pricing honest)

T-shirt size discipline¶

[Critical] Is the T-shirt size cardinality bounded to a target of 5-7 sizes covering 90 percent or more of historical request volume, with the long tail explicitly routed through a separate custom-request path rather than enumerated as additional T-shirt sizes? (catalogs that enumerate every CPU/RAM/disk combination commonly end up with 100+ or 500+ sizes, which destroys the cost-discipline benefit T-shirts are supposed to provide; the discipline is to fit the request distribution to a small set of sizes, not to fit the sizes to the request distribution; analyzing the prior 12-24 months of VM requests for CPU/RAM/disk distribution is the data-driven way to define the 5-7 sizes)
[Critical] What sizing dimensions does each T-shirt actually fix -- vCPU count, RAM, ephemeral disk size, attached storage tier, network tier, OS family -- and which dimensions are independently selectable on the form vs bundled into the T-shirt itself? (bundling everything into the T-shirt minimizes form variables but cannot express realistic combinations like "M-size compute with high-IOPS storage"; making everything independently selectable defeats the T-shirt; the pragmatic split is to bundle vCPU and RAM into the T-shirt and let storage tier, attached storage volume, and network tier vary as separate variables)
[Recommended] Is the T-shirt naming convention chosen -- abstract (XS / S / M / L / XL), descriptive (Small Web / Medium Database / Large Compute), or cost-band (Tier-1 / Tier-2 / Tier-3) -- and applied consistently across all catalog items and hypervisors? (abstract names are easy to scan and language-neutral but require a legend; descriptive names communicate intent but constrain reuse across workloads; cost-band names tie the T-shirt directly to the chargeback model and are most defensible for finance audiences -- choose one and stay consistent)
[Recommended] Is per-environment T-shirt variation defined -- can a Production-Medium be specced differently from a Dev-Medium, and does the form show only the environment-appropriate sizes? (production workloads often demand higher reservation, redundancy, and storage tier than dev/test at the same logical T-shirt; conflating them in the form forces either over-provisioning of dev/test or under-provisioning of production; the cleanest pattern is a separate environment variable that gates which T-shirts and which storage/network options are presented)
[Recommended] Is there a defined escape-valve workflow for requests that do not fit any T-shirt -- separate catalog item, deeper approval chain, capacity-planning review -- so the long tail does not pressure the T-shirt menu to grow? (without an explicit escape valve, every odd request becomes an argument for adding another size; with the escape valve, edge cases are routed through a deliberate review where capacity planning and finance can be brought in; the escape-valve path should have an explicitly slower SLA than the standard T-shirt path to keep it as an exception rather than a default)

Cost factors and data sources¶

[Critical] Which cost factors are included in the request-time displayed estimate vs included only in the post-provisioning chargeback report, and is the choice consistent with what the back-end pricing layer can actually produce at form-fill latency? (compute is almost always included and is reliably available from rate-card lookup or provider pricing API; software licensing varies depending on BYOL vs PAYG and on per-vCPU vs per-VM metrics; backup, network egress, management overhead, and power/cooling typically have monthly or per-event data sources and may not be available at form-fill time; the design decision is which factors materially change the requester's choice and therefore belong in the estimate vs which only matter to the finance close)
[Critical] For each included cost factor, what is the data source, the refresh cadence, and the fallback when the source is unavailable? (compute pricing from Azure Retail Prices API and AWS Pricing API refreshes daily, VMware private-cloud rate from a manually-curated rate card refreshes quarterly or annually, CloudHealth blended cost refreshes daily; the catalog form needs each factor's freshness contract documented so that a stale source can be flagged rather than silently displayed as authoritative)
[Recommended] Are network egress and data-transfer costs handled explicitly -- either included with a stated assumption (per-VM allocation, traffic estimate per T-shirt size) or excluded with a visible disclaimer? (egress is the most commonly invisible cost in catalog pricing because it depends on actual traffic patterns rather than provisioned capacity; estimates that exclude egress without saying so produce sticker-shock disputes when the chargeback statement arrives; the right pattern is either a per-T-shirt traffic assumption with a documented basis or an explicit "egress not included, see post-provisioning chargeback" note)
[Recommended] Are management-overhead costs -- ServiceNow license per managed VM, monitoring agent per VM, backup software per VM, managed-services per-VM operations fee -- modeled and either included in the estimate or excluded with a stated reason? (these are typically 10-30 percent of total VM cost and are the second most common silent under-count after egress; the design choice is whether the request-time estimate is fully-loaded or compute-only, and either is defensible but the choice must be explicit and visible to the requester)

Multi-hypervisor catalog patterns¶

[Critical] When the catalog spans multiple hypervisors (Azure, VMware, Nutanix, AWS, GCP, OpenStack, OpenShift, others), is the catalog structure chosen -- Order Guide that branches to hypervisor-specific catalog items, single catalog item with form variables that branch on hypervisor selection, or per-hypervisor catalog items the user navigates to directly -- and is the choice driven by how different the per-hypervisor fulfillment workflows actually are? (Order Guide is the cleanest when fulfillment differs substantially per hypervisor because each downstream catalog item can have its own variables, validation, and workflow; single-item-with-branching is appropriate when the form and workflow are mostly common and only specific variables vary; per-hypervisor items work when the user community knows which hypervisor they want and does not benefit from a chooser layer)
[Critical] Is the user-facing UX consistent across hypervisors -- same T-shirt size labels, same environment options, same cost-factor disclosure -- regardless of which back-end ultimately fulfills the request? (presenting Azure-D2s-v5 vs VMware-Medium vs Nutanix-AHV-Std-2C8G as the size choices forces the requester to understand back-end implementation details that should be invisible; the discipline is to define abstract T-shirts that map to per-hypervisor SKUs at fulfillment time, not at form-fill time -- this also makes the hypervisor selection a true choice for the requester rather than a forced consequence of size selection)
[Recommended] Is the per-hypervisor cost-data plumbing identified and confirmed feasible before the unified catalog goes live -- Azure Retail Prices API or Azure Cost Management API for Azure, Broadcom CloudHealth or Aria Cost or a curated rate card for VMware, Nutanix Prism Central plus per-resource accounting for Nutanix, AWS Pricing API for AWS, GCP Cloud Billing for GCP -- and is the refresh cadence of each one understood? (a unified catalog whose pricing is daily-fresh for Azure but quarterly-stale for VMware will produce dispute volume on the stale side; the right pattern is either to harmonize cadence by adopting a single FinOps platform that ingests from all back ends, or to disclose the per-hypervisor freshness in the basis-of-estimate text)
[Recommended] Is hypervisor selection on the catalog landing page a true business choice (placement policy, data sovereignty, performance tier, cost band) rather than a forced implementation detail, and is the user given the cost comparison across hypervisors before selecting? (showing the same T-shirt priced for each available hypervisor inline turns the catalog into a placement-decision tool; hiding the comparison and forcing the user to pick a hypervisor first treats the catalog as a fulfillment dispatcher; the choice should reflect the organization's actual placement-policy maturity, not the path of least implementation effort)

Finance-approval workflow¶

[Critical] Is the finance-approval threshold and routing defined -- auto-approve below $X per month, route to cost-center owner up to $Y, route to finance above $Y, with escalation paths -- and is the threshold tied to the request-time estimate or to a post-provisioning recalculation? (auto-approval thresholds tied to the pre-submission estimate produce fast turnaround but rely on estimate accuracy; thresholds tied to post-provisioning actuals are more defensible but force every request through approval; the pragmatic pattern is to use the pre-submission estimate for the threshold decision while reserving the right to re-route if the post-provisioning actual exceeds the band by more than a stated tolerance)
[Critical] Is the cost-center code captured at form-fill time with validation against the active list, and is the requester's authority to charge that cost-center verified before submit -- through ServiceNow identity-to-cost-center mapping, manager attestation, or external HR-system lookup? (cost-center codes typed freehand drift toward invalidity over time as the cost-center master list changes; an unvalidated code routes the approval to finance and the dispute back to the requester; the design choice is between an inline picker against a synced cost-center table, a defaulted value from the requester's profile that can be overridden, or both)
[Recommended] Are approval-aging SLAs defined per cost band -- 24 hours for the auto-approval band, 48 hours for cost-center-owner approval, 72 hours for finance approval -- with auto-escalation when SLAs are missed? (without aging SLAs, finance approval becomes the variable-time step that the requester cannot plan around; defining the SLA and the escalation makes the finance step predictable and surfaces approval-process bottlenecks for management attention)
[Recommended] Is there an out-of-band fast-path for time-critical requests (incident response, outage recovery, business-emergency provisioning) that bypasses the standard finance-approval routing with a documented post-fact reconciliation, and is misuse of the fast-path tracked? (without a fast-path, every emergency provisioning attempts to bypass the catalog entirely and the catalog's cost-discipline benefit is lost on the requests that matter most; with a fast-path that is not monitored, the fast-path becomes the default; the discipline is to provide the path and to report on its usage so abuse is visible)

Reconciliation and ongoing operations¶

[Recommended] Is a monthly close process defined that locks the request-time estimate displayed at submission, reconciles it against the actual post-provisioning cost for the same VM, and surfaces variance to finance and to the catalog owner? (this is the operational feedback loop that keeps the estimate honest; without it, estimate-to-actual drift accumulates and the catalog's request-time pricing loses credibility over time; locking the estimate at submission is the prerequisite for the reconciliation -- a recomputed-on-demand estimate cannot be reconciled because there is no fixed value to compare against)
[Recommended] Are per-team showback reports generated from the catalog-submission data, with drill-down from the team total to the individual VM and back to the originating catalog request, and is this report accessible to the team owner rather than only to finance? (the catalog request is the only place where the cost-allocation metadata -- cost center, application, owner -- is captured at the moment of intent; making that data the basis of a self-service showback report closes the loop between request, provisioning, and accountability; this is the request-time-UX analog to the tagging-compliance feedback loop described in patterns/vmware-servicenow-chargeback.md)

Why This Matters¶

The catalog-form FinOps surface is where the cost-allocation model meets the requester's daily reality, and the design of that surface determines whether the organization's chargeback program actually changes provisioning behavior or whether it merely produces a monthly statement that gets disputed. A well-designed catalog asks a small number of T-shirt-size questions, surfaces an estimate the user sees before submitting, captures the cost-center coding inline, and routes a budget-aware ticket to a finance-approval step that is predictable rather than mysterious. A poorly-designed one either hides cost entirely until after the request is fulfilled (which defeats the chargeback feedback loop because the cost arrives weeks after the decision that produced it) or exposes a 500-size T-shirt matrix that paralyzes the user into picking the largest plausible size every time (which defeats both cost discipline and capacity planning). Both failure modes are common because the design questions that distinguish them are rarely owned by anyone in particular: catalog UX is typically owned by a ServiceNow administrator, T-shirt sizing is typically owned by an infrastructure architect, and cost presentation is typically owned by finance -- and the three groups frequently do not collaborate on the form itself.

The single most common specific failure is post-submission cost shock. A request goes in with no visible price, the VM is provisioned, the monthly chargeback statement arrives, and the cost is higher than the requester expected because backup, egress, and management overhead were not in their mental model. The team disputes the chargeback, finance investigates, and the next several months are spent rebuilding credibility for a chargeback program that was never wrong on the actual numbers -- it was wrong on the request-time transparency. Pre-submission cost estimates with clearly labeled basis-of-estimate text are the structural fix for this failure mode; a hybrid model in which a non-authoritative pre-submission estimate is paired with an authoritative post-submission calculation produces both the transparency and the accuracy, at the cost of explicit user-facing language about which number is which. The hybrid model is the most common production pattern in mature organizations, but it requires discipline to land correctly because the temptation to either drop the pre-submission number (because it is not authoritative) or to upgrade it to authoritative (because users want the simple story) destroys the design.

The 500-size T-shirt menu is the second specific failure mode, and it is structural rather than tactical. It emerges when the catalog accepts requests for "one more size" without a discipline that pushes those requests through an escape-valve workflow instead. Every additional size feels small at the time -- one more row in a table, one more option in a dropdown -- but the cumulative effect is a form that nobody can pick from, which forces the requester to either pick the largest plausible option (over-provisioning the estate) or to ask a human for help (defeating the catalog's self-service goal). The cardinality discipline is therefore enforced not by the catalog UX itself but by the request-process governance: the answer to "we need another size for this special case" is the escape-valve catalog item, not another T-shirt row. Without that discipline, the catalog optimizes itself toward unusability over a multi-year horizon.

Multi-hypervisor catalogs add a third dimension of failure because the cost-data freshness and the per-hypervisor SKU vocabulary differ. A request that the requester sees priced at one number on Azure and a different number on VMware is doing the catalog's job when those numbers are real; it is creating dispute volume when one of them is six months stale. The harmonization decision -- adopt a single FinOps platform that ingests from all back ends, or disclose the per-hypervisor freshness inline -- is the structural choice that determines whether the multi-hypervisor catalog is a placement-decision tool or a placement-confusion tool. Organizations that skip this decision and ship a unified catalog with stale VMware pricing alongside fresh Azure pricing predictably end up with VMware looking artificially cheap and the catalog driving placement decisions in a direction the finance team did not intend.

Common Mistakes¶

Shipping a catalog without any request-time cost display, then being surprised when the chargeback statement produces disputes. Post-submission cost calculation is a defensible pattern, but only if paired with explicit user-facing language at request time about how the chargeback will be computed; absent that language, the user has no basis to anticipate the bill.
Enumerating every CPU/RAM/disk combination as a separate T-shirt size. The forms that result are unusable; the discipline is to fit the request distribution to 5-7 sizes plus an escape valve, not to enumerate the distribution.
Including only compute cost in the request-time estimate and silently omitting backup, egress, and management overhead. This is the single most common cause of chargeback-statement disputes; either include the factors or label the exclusion visibly.
Building the catalog without first confirming what the back-end pricing layer can produce at form-fill latency. Catalog forms that depend on a pricing service which is unreachable, slow, or has stale data degrade to either error states or silently-wrong numbers; both are worse than not showing a number at all.
Routing every request through finance approval regardless of size. The auto-approval threshold is the mechanism that keeps finance focused on the requests that matter; without it, finance approval becomes the variable-time bottleneck the requester cannot plan around.
Shipping a multi-hypervisor catalog with per-hypervisor cost-data refresh cadences that differ by months. The hypervisor with the stale cost data will look artificially cheap or artificially expensive depending on the direction of drift, and the catalog will systematically distort placement decisions away from finance's intent.
Treating the request-time estimate as authoritative and dropping the post-submission reconciliation. The estimate is unverified until reconciled against actuals; without the reconciliation step, estimate accuracy degrades silently and the catalog's pricing loses credibility over time.

Key Patterns¶

Hybrid pre-and-post-submission pricing. A clearly-labeled pre-submission estimate gives the requester transparency at form-fill time; the post-submission calculation is authoritative for budget allocation and ERP journal entries. The user-facing language has to distinguish the two without confusing the requester. This is the most common production pattern in organizations with mature catalog FinOps.
5-7 T-shirts plus an explicit escape valve. The T-shirt menu covers 90 percent of requests and is bounded by a cardinality discipline; the long tail goes through a separate custom-request workflow with deeper approval and a slower SLA. The escape valve is what protects the T-shirt menu from accreting sizes nobody picks.
Bundled compute T-shirt plus independent storage and network variables. Bundling vCPU and RAM into the T-shirt minimizes form complexity; making storage tier and network tier independently selectable lets the form express realistic combinations like "M-size compute with high-IOPS storage" without exploding the T-shirt count.
Abstract T-shirt labels with per-hypervisor SKU mapping at fulfillment time. The user sees Small / Medium / Large; the fulfillment workflow maps to Azure D2s-v5 or VMware-Medium-Profile or Nutanix-AHV-Std-2C8G. The user is making a placement choice on cost and performance, not on back-end SKU vocabulary.
Fully-loaded estimate with visible basis-of-estimate text. Include compute, software licensing, backup, egress (with stated assumptions), and management overhead in the request-time estimate; surface the rate-card date, the included/excluded factors, and the per-hypervisor freshness inline so the requester can interpret the number. This is more work than a compute-only estimate but produces dramatically lower dispute volume.
Tiered finance approval with auto-approval band, cost-center-owner band, and finance band. Auto-approval below a small threshold removes finance from low-stakes requests; cost-center-owner approval handles the middle band; finance approval handles the high band and the edge cases. Each band has a defined aging SLA so the requester can plan around it.
Monthly close with estimate-to-actual reconciliation. The pre-submission estimate is locked at submission; the post-provisioning actual is computed at month-end; variance is surfaced to finance and to the catalog owner as the feedback loop that keeps estimate accuracy from degrading silently.

Common Decisions (ADR Triggers)¶

Pre-submission cost estimate vs post-submission cost calculation vs hybrid. Pre-submission gives transparency and accelerates finance approval but depends on a price-resolver that can run at form-fill latency; post-submission produces authoritative pricing but defers visibility until after submit and can produce sticker shock; hybrid pairs an informational pre-submission estimate with an authoritative post-submission calculation and is the most common production pattern, but requires explicit user-facing language to land correctly.
T-shirt size cardinality: 5-7 bounded sizes plus escape valve vs continuous configuration vs enumerated full matrix. Bounded sizes preserve cost discipline and produce a usable form but require an escape-valve workflow for the long tail; continuous configuration (user picks any vCPU/RAM combination) maximizes flexibility but eliminates the cost-discipline benefit and complicates pricing; enumerated full matrix (every combination as a separate size) is the most common failure mode and produces unusable forms.
Cost-factor display scope: compute-only vs fully-loaded estimate vs explicit hybrid with disclosed exclusions. Compute-only is the easiest to implement and produces the most dispute volume after the chargeback statement; fully-loaded is the most defensible but requires every factor's data source to be available at form-fill latency or with a clearly-documented assumption; explicit hybrid (compute plus stated assumptions for backup and egress, with management overhead excluded and disclosed) is the pragmatic middle ground.
Finance approval position: before provisioning vs after provisioning vs tiered with auto-approval band. Before-provisioning ensures finance signs off but slows every request by the approval cycle; after-provisioning accelerates fulfillment but creates a reversal problem if finance declines; tiered with an auto-approval band keeps finance focused on the requests that matter and is the most common production pattern.
Multi-hypervisor catalog structure: Order Guide vs single catalog item with branching variables vs per-hypervisor catalog items. Order Guide is cleanest when fulfillment differs substantially per hypervisor; single-item-with-branching is appropriate when most of the form and workflow are common; per-hypervisor items work when the user community knows which hypervisor they want. The choice is downstream of how different the per-hypervisor fulfillment workflows actually are, and reversing it later is expensive.
Pricing engine: ServiceNow Financial Management module vs ServiceNow Cloud Cost Management vs third-party FinOps platform (Apptio, CloudHealth, Vantage, Nicus) feeding the catalog estimate vs custom rate-card table in ServiceNow. Native ServiceNow Financial Management minimizes integration but historically has weaker private-cloud depth; Cloud Cost Management is the newer ServiceNow positioning; third-party FinOps platforms provide stronger multi-cloud aggregation but add a callout dependency at form-fill time; a custom rate-card table is the simplest to implement and the most manual to keep current. Choice depends on the back-end mix and on whether a FinOps platform is already in use for patterns/vmware-servicenow-chargeback.md.
Tag-governance dependency. The catalog form is where cost-allocation metadata (cost center, application, owner, environment) is captured at the moment of intent; this is the upstream of the 90-95 percent tagging coverage gate from general/finops.md. The design choice is whether the catalog form mandates these fields (form-level validation, no submit without them) or treats them as optional with downstream remediation, and the choice materially affects whether the chargeback program will clear the tagging gate at scale.

Reference Architectures and Links¶

ServiceNow Service Catalog -- product positioning for Service Catalog, including Order Guides, Catalog Items, Record Producers, and Service Portal storefronts
ServiceNow Financial Management -- Financial Management module for showback, chargeback, and budget allocation inside ServiceNow
ServiceNow Cloud Cost Management -- newer ServiceNow positioning for multi-cloud cost management integrated with the platform
ServiceNow Flow Designer -- flow authoring used for catalog fulfillment workflows including approval steps
Azure Retail Prices API -- public price-list API suitable for catalog-form pricing lookups against Azure SKUs
AWS Price List API -- public price-list API for AWS SKUs, used similarly for catalog pricing lookups
FinOps Foundation Framework -- vendor-neutral framework for the Inform / Optimize / Operate phases that the catalog UX supports
FinOps Foundation Personas -- engineering, finance, and product personas whose competing interests the catalog UX has to balance