Product Inventory & Subscription Lifecycle
Product Inventory: The BSS Runtime View
Product Inventory is the BSS-side source of truth for what each customer currently has. It holds every product instance — every subscription, every add-on, every bundle — with its commercial characteristics, lifecycle state, and billing associations. If the Product Catalog says "here is what we sell," Product Inventory says "here is what customer X actually bought."
This is the inventory layer that customer-facing teams interact with most. When a call-centre agent looks up a customer, they are reading Product Inventory. When the self-service portal shows "Your Services," it is querying Product Inventory. When billing calculates monthly charges, it reads Product Inventory.
Product Instance vs Product Specification
A Product Specification in the catalog is a template: it defines the structure, allowed characteristics, and constraints of a product type. A Product Instance in inventory is a concrete occurrence of that template, created for a specific customer with specific values.
Specification vs Instance
| Aspect | Product Specification (Catalog) | Product Instance (Inventory) |
|---|---|---|
| Nature | Template / blueprint | Concrete occurrence |
| Quantity | One per product type | One per customer subscription |
| Characteristics | Defines allowed values (e.g., speed: 50/100/200 Mbps) | Holds actual value (e.g., speed: 200 Mbps) |
| Lifecycle | Draft → Published → Retired | Created → Active → Suspended → Terminated |
| Customer link | None — it is a template | Linked to a specific Customer and Billing Account |
| Price | Defines pricing rules and options | Records the actual price applied (after promotions) |
| TMF API | TMF620 Product Catalog Management | TMF637 Product Inventory Management |
Anatomy of a Product Instance
A product instance in inventory is a rich data structure. Understanding its components is essential for anyone working with BSS integration, billing, or CRM.
Product Instance Data Elements
| Element | Description | Example |
|---|---|---|
| Instance ID | Unique identifier for this product instance | PI-88421 |
| Product Spec Reference | Link to the catalog specification | PS-HOME-BB-v2.1 |
| Customer Reference | The customer who owns this product | CUST-42817 |
| Billing Account | Account responsible for payment | BA-ACC-9912 |
| Lifecycle State | Current state in the product lifecycle | Active |
| Characteristics | Customer-specific attribute values | speed=200Mbps, routerIncluded=true |
| Start Date / End Date | Activation and contract termination dates | 2024-06-01 / 2026-06-01 |
| Applied Prices | Actual pricing after discounts/promotions | $59.99/month (list: $74.99) |
| Related Instances | Links to child/parent product instances | Parent: BUNDLE-PI-8800 |
| Service References | Links to CFS instances in Service Inventory | SI-CFS-INT-ACCESS-88421 |
Subscription Lifecycle Management (SLM)
Subscription Lifecycle Management (SLM) is the discipline of managing product instances from creation through to termination. SLM encompasses all the state transitions a subscription goes through, the business rules that govern those transitions, and the events that trigger downstream processes.
Product instance lifecycle states and valid transitions — each state drives billing and service behaviour
Product Instance Lifecycle States
Every product instance moves through a defined set of lifecycle states. While exact state names vary by vendor, the core states are consistent across the industry.
The product instance has been created in inventory but is not yet active. This happens when an order has been placed but fulfilment is still in progress. The customer does not yet have the service, and billing has not started.
- Triggered by: Commercial order acceptance
- Billing impact: No charges yet
- Service impact: Service instances may be in "Designed" or "Reserved" state
- Typical duration: Hours to days (depends on fulfilment complexity)
State Transitions and Business Rules
Not all state transitions are allowed. Business rules govern which transitions are valid and what conditions must be met. For example, you cannot move directly from "Created" to "Terminated" without passing through "Active" first (in most implementations).
Valid State Transitions
| From State | To State | Trigger | Conditions |
|---|---|---|---|
| Created | Active | Activation confirmation | All service/resource instances successfully activated |
| Created | Cancelled | Order cancellation | Within cancellation window, no resources allocated |
| Active | Suspended | Suspension request | Valid reason (non-payment, customer request, fraud) |
| Active | Pending Disconnect | Disconnection request | Contract terms checked, early termination fees calculated |
| Suspended | Active | Resumption request | Suspension reason resolved (payment received, etc.) |
| Suspended | Terminated | Termination after suspension period | Max suspension duration exceeded |
| Pending Disconnect | Active | Disconnect reversal | Within grace period, customer requests retention |
| Pending Disconnect | Terminated | Grace period expired | Final billing complete, resources released |
Cascading State Changes Across Layers
When a product instance changes state, this must cascade down through the service and resource layers. A suspended product means suspended services and (optionally) suspended resource configurations. A terminated product means terminated services and deallocated resources. This cascade is a core responsibility of the order management / fulfilment chain.
Example: Suspension Cascade
Product Suspended
Product Inventory (BSS)Product Inventory updates product instance state to "Suspended" due to non-payment. A suspension event is published.
Service Suspension Initiated
SOM (OSS)SOM receives the suspension event and creates a modify service order to suspend all linked CFS instances.
CFS/RFS Suspended
Service Inventory (OSS)Service Inventory updates CFS and RFS instances to "Suspended" state. Service-level configurations may be modified (e.g., redirect to payment portal).
Resource Reconfigured
Resource Inventory / ActivationActivation engine applies suspension configuration to resources (e.g., apply walled-garden policy, restrict bandwidth). Resources remain allocated but service is restricted.
Product Instance Relationships
Product instances in inventory have relationships, mirroring the catalog's product structure. A bundle product instance contains child product instances. A primary product instance may have dependent add-on instances. Understanding these relationships is critical for lifecycle management — you cannot terminate a parent bundle without terminating its children.
- Bundle → Component: A "Triple Play" bundle instance contains Broadband, Voice, and IPTV component instances
- Primary → Add-on: A "Broadband" primary instance has "Static IP" and "Speed Boost" add-on instances
- Dependency: A "Mobile Handset" product instance depends on a "Mobile Plan" product instance
- Cross-product: A "Multi-Play Discount" instance references both Fixed and Mobile product instances
TMF637 Product Inventory Management API
TMF637 is one of the most widely implemented TMF Open APIs because Product Inventory is consumed by so many systems: billing, CRM, self-service portals, analytics, and assurance.
TMF637 Key Operations
| Operation | Method | Purpose | Example |
|---|---|---|---|
| List Products | GET /product | Retrieve product instances with filtering | GET /product?relatedParty.id=CUST-42817&state=active |
| Get Product | GET /product/{id} | Retrieve a specific product instance | GET /product/PI-88421 |
| Create Product | POST /product | Create a new product instance (typically by fulfilment) | POST with product spec ref, customer, characteristics |
| Update Product | PATCH /product/{id} | Modify characteristics or state | PATCH /product/PI-88421 with new speed value |
| Delete Product | DELETE /product/{id} | Remove a product instance (rare — usually state change to Terminated) | Typically not used; state change preferred |
Product Inventory in Practice
Think of Product Inventory as a customer's account statement. It lists everything they have subscribed to, the current status of each subscription, and what they are paying. When you log into your broadband provider's website and see "Your Services," that is Product Inventory.
Product Inventory typically integrates with:
- CRM: Displays product instances on the customer profile — read access
- Billing: Reads product instances to generate charges — read access with event subscription
- Self-Service Portal: Shows customers their subscriptions — read access via BFF
- Order Management (COM): Creates and modifies product instances during fulfilment — write access
- SOM: Receives product instance references to correlate with service instances — reference access
- Analytics: Reads product inventory for subscriber base analysis — bulk read access
In large-scale deployments, Product Inventory must handle millions of product instances with sub-second query times. Common architectural patterns include: (1) CQRS — separate command and query models, optimizing writes for fulfilment and reads for CRM/portal; (2) Event sourcing — storing every state change as an event, enabling audit trails and temporal queries; (3) Sharding — partitioning by customer ID or region for horizontal scalability; (4) Read replicas — dedicated read copies for high-traffic consumers like self-service portals.
Product Inventory must also support effective dating — the ability to record future state changes (e.g., a plan upgrade scheduled for the next billing cycle) and historical state queries (e.g., "what was this customer's plan on January 15th?"). This temporal dimension adds significant complexity to the data model.
Modify and Disconnect Flows
Product Inventory is not only populated during initial order fulfilment. It is continuously updated throughout the subscription lifecycle as customers change plans, add services, or disconnect.
A modify order changes the characteristics or composition of an existing product instance. For example, upgrading from 100Mbps to 200Mbps, or adding a Static IP add-on.
Modify Flow Impact on Product Inventory
Modify Order Placed
COM (BSS)Customer requests upgrade from 100Mbps to 200Mbps. COM creates a modify order.
Product Instance Updated
Product Inventory (BSS)Product Inventory updates the speed characteristic from 100 to 200 and adjusts the applied price. State may temporarily be "Pending Modify".
Service Modification Triggered
Service Inventory (OSS)The change cascades to Service Inventory — CFS instance speed attribute is updated, and RFS modifications are orchestrated.
Confirmation and Billing Update
Product Inventory / Billing (BSS)Once activation confirms the change, Product Inventory state returns to Active with updated characteristics. Billing picks up the new price.
Product Inventory Source of Record
Product Inventory SoR Mapping
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Product Instance (subscription) | Product Inventory / CRM | Self-Service Portal, Agent Desktop | Billing, Analytics, Service Inventory | The authoritative record of what the customer has bought. |
| Product Instance State | Product Inventory | COM (triggers state changes via orders) | Billing (charge start/stop), CRM (display) | State drives billing and service availability. |
| Applied Prices | Product Inventory / Rating Engine | COM (applies during order), Promotion Engine | Billing (invoice generation) | Price after all discounts and promotions. |
| Contract Terms | Product Inventory / Contract Management | Sales channels (during sale) | Billing (ETF calculation), Retention team | Minimum term, renewal date, penalties. |
Product Inventory as the Commercial Truth
Product Inventory is the single commercial truth. When any system needs to answer "what does this customer have and what are they paying?", Product Inventory is the answer.
Section 4.2 Key Takeaways
- Product Inventory holds the runtime, customer-specific view of subscriptions — not the catalog template
- Each product instance references a Product Specification and holds customer-specific characteristic values
- Lifecycle states (Created, Active, Suspended, Terminated) drive billing and service availability
- State changes cascade across inventory layers: product change triggers service and resource changes
- TMF637 provides standardized CRUD and event notification for product instances
- Product instance relationships (bundle, add-on, dependency) must be integrity-checked during lifecycle changes
- Product Inventory is the Source of Record for the commercial subscription — billing, CRM, and portals all reference it