Home / architect / revenue-cloud-architecture
revenue-cloud-architecture
Architecting on Salesforce Revenue Cloud (Revenue Lifecycle Management — RLM, the successor to CPQ-Plus + Billing).
Open the skill folder on GitHub
Revenue Cloud Architecture
"Revenue Cloud" is Salesforce's umbrella for quote-to-cash. The modern stack is Revenue Lifecycle Management (RLM) — a native, five-domain architecture that replaces the prior generation built on the CPQ classic managed package (SBQQ__ namespace) and the Salesforce Billing managed package (blng__ namespace). Many orgs run a hybrid because RLM's adoption has been gradual.
This skill is an architecture reference. It maps the RLM domains to their canonical objects, names the integration patterns Salesforce Architects publishes for RLM <-> ERP, and disambiguates RLM from the legacy products it replaces (a frequent LLM confusion).
The five RLM domains
RLM organizes the quote-to-cash lifecycle into five composable domains. Each owns a set of objects and a slice of behavior.
| Domain | Owns | Key Objects |
|---|---|---|
| Product Catalog & Pricing | Catalog, configurations, pricing rules | Product2, Pricebook2, PricebookEntry, attribute / category metadata |
| Transaction Management | Quote, configure-price-quote, order capture | Quote, QuoteLineItem, Order, OrderItem |
| Contract Lifecycle Management | Contracts, amendments, renewals | Contract, ContractLineItem |
| Order-to-Cash | Order fulfillment, asset lifecycle | Order, OrderItem, Asset, AssetStatePeriod |
| Billing | Invoicing, revenue, payments, accounting | BillingSchedule, Invoice, InvoiceLine, LegalEntity, AccountingPeriod |
The objects are not unique to one domain — Order participates in Transaction Management (capture) and Order-to-Cash (fulfillment). The five-domain map is conceptual. It guides which team owns what and where to put extension logic.
Multi-entity: the LegalEntity object
LegalEntity is the linchpin for multi-subsidiary setups. Invoices, accounting periods, payment terms, and tax-treatment metadata can be scoped per LegalEntity. One Salesforce org can run several legal entities concurrently.
The risk: entity proliferation. Without governance, every regional finance team wants a separate LegalEntity, and tax / accounting configuration multiplies. Architect default: start with the smallest LegalEntity count that satisfies legal / accounting separation, expand only with finance approval.
RLM <-> ERP integration patterns
The reference pattern published by Salesforce Architects is event-driven, not point-to-point. The recipe:
- Outbound from Salesforce to ERP. Use Change Data Capture
on Order / OrderItem / Invoice consumed via CometD, MuleSoft, or a Pub/Sub API client. Or publish a Platform Event from a trigger and have the ERP subscribe.
- Outbound via Apex callout. Trigger-time callouts are blocked
(synchronous callouts from triggers aren't allowed). Use
@future(callout=true)or Queueable withDatabase.AllowsCalloutsfor fire-and-forget; for transactional integration, the event-driven path is preferred. - Inbound from ERP. REST or Bulk API loads, gated through
LegalEntityscoping and validation.
The anti-pattern: writing a synchronous Apex trigger that calls the ERP REST API on every Order insert. It cannot work synchronously (blocked) and even when async it tightly couples Salesforce deployments to ERP availability.
Disambiguating RLM, CPQ classic, and Salesforce Billing
| Term | Meaning |
|---|---|
| Revenue Cloud | Marketing umbrella; refers to RLM in modern docs |
| RLM (Revenue Lifecycle Management) | Native quote-to-cash, no managed package |
| CPQ classic | SBQQ__ managed package; the predecessor to RLM Transaction Management |
| Salesforce Billing | blng__ managed package; the predecessor to RLM Billing |
| Subscription Management | Older subscription billing product, distinct from both above |
LLMs frequently conflate RLM Billing with the blng__ package. They are different products with different objects, different APIs, and different upgrade paths. Confirm namespace before designing.
Recommended Workflow
- Confirm which products are licensed and active. RLM, CPQ classic, Salesforce Billing, and Subscription Management can coexist. Discover the actual managed-package state via Setup -> Installed Packages.
- Map the business process to the five RLM domains. Identify which domain owns which step. This determines which objects to extend and which team is responsible.
- Plan multi-entity scoping early. Decide LegalEntity count and granularity before any data model extension. Adding entities mid-flight is disruptive.
- Choose ERP integration shape per direction. Outbound preferred via CDC / Platform Events. Inbound via REST / Bulk API gated through LegalEntity validation. Document the contract per direction.
- Avoid synchronous trigger callouts. They are blocked by the platform; the alternative is
@future(callout=true)or Queueable, but the architect-recommended pattern is event-driven. - Stand up sandbox tests for each integration path. Failure modes (ERP down, slow, malformed response) need explicit handling. Replay-from-CDC checkpointing is the durable pattern.
- Document the namespace decision. Make explicit in the architecture record whether the integration targets native RLM objects,
SBQQ__CPQ classic,blng__Salesforce Billing, or a hybrid. This prevents downstream confusion for the next team.
What This Skill Does Not Cover
| Topic | See instead |
|---|---|
| Declarative CPQ classic configuration | omnistudio/cpq-classic-config |
| CPQ-classic specific quoting patterns | architect/cpq-architecture-patterns |
| Subscription Management (legacy) billing patterns | architect/cpq-architecture-patterns |
| ERP-side connector implementation | integration/named-credential-patterns |