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 with Database.AllowsCallouts
for fire-and-forget; for transactional integration, the
event-driven path is preferred.
- Inbound from ERP. REST or Bulk API loads, gated through
LegalEntity scoping 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 |
1---2name: revenue-cloud-architecture3description: Architecting on Salesforce Revenue Cloud (Revenue Lifecycle Management — RLM, the successor to CPQ-Plus + Billing). Covers the five RLM domains (Product Catalog & Pricing, Transaction Management, Contract Lifecycle Management, Order-to-Cash, Billing), the canonical data model (Product2 / PricebookEntry / Quote / Order / OrderItem / Contract / Asset / BillingSchedule / Invoice / LegalEntity), multi-entity scoping via LegalEntity, the RLM ↔ ERP integration patterns (CDC + MuleSoft preferred over point-to-point trigger callouts), and the disambiguation between native RLM and the legacy `blng__` Salesforce Billing managed package and `SBQQ__` CPQ classic. NOT for implementing DRO fulfilment plans or Connect API billing schedules - use integration/revenue-lifecycle-management. NOT for CPQ classic bundle, pricing and quoting architecture - use architect/cpq-architecture-patterns.4---56# Revenue Cloud Architecture78"Revenue Cloud" is Salesforce's umbrella for quote-to-cash. The9modern stack is **Revenue Lifecycle Management (RLM)** — a native,10five-domain architecture that replaces the prior generation built on11the CPQ classic managed package (`SBQQ__` namespace) and the12Salesforce Billing managed package (`blng__` namespace). Many orgs13run a hybrid because RLM's adoption has been gradual.1415This skill is an architecture reference. It maps the RLM domains to16their canonical objects, names the integration patterns Salesforce17Architects publishes for RLM <-> ERP, and disambiguates RLM from the18legacy products it replaces (a frequent LLM confusion).1920## The five RLM domains2122RLM organizes the quote-to-cash lifecycle into five composable23domains. Each owns a set of objects and a slice of behavior.2425| Domain | Owns | Key Objects |26|---|---|---|27| Product Catalog & Pricing | Catalog, configurations, pricing rules | `Product2`, `Pricebook2`, `PricebookEntry`, attribute / category metadata |28| Transaction Management | Quote, configure-price-quote, order capture | `Quote`, `QuoteLineItem`, `Order`, `OrderItem` |29| Contract Lifecycle Management | Contracts, amendments, renewals | `Contract`, `ContractLineItem` |30| Order-to-Cash | Order fulfillment, asset lifecycle | `Order`, `OrderItem`, `Asset`, `AssetStatePeriod` |31| Billing | Invoicing, revenue, payments, accounting | `BillingSchedule`, `Invoice`, `InvoiceLine`, `LegalEntity`, `AccountingPeriod` |3233The objects are not unique to one domain — `Order` participates in34Transaction Management (capture) and Order-to-Cash (fulfillment).35The five-domain map is conceptual. It guides which team owns what36and where to put extension logic.3738## Multi-entity: the LegalEntity object3940`LegalEntity` is the linchpin for multi-subsidiary setups. Invoices,41accounting periods, payment terms, and tax-treatment metadata can be42scoped per `LegalEntity`. One Salesforce org can run several legal43entities concurrently.4445The risk: entity proliferation. Without governance, every regional46finance team wants a separate `LegalEntity`, and tax / accounting47configuration multiplies. Architect default: start with the smallest48`LegalEntity` count that satisfies legal / accounting separation,49expand only with finance approval.5051## RLM <-> ERP integration patterns5253The reference pattern published by Salesforce Architects is54event-driven, not point-to-point. The recipe:5556- **Outbound from Salesforce to ERP.** Use **Change Data Capture**57 on Order / OrderItem / Invoice consumed via CometD, MuleSoft, or58 a Pub/Sub API client. Or publish a **Platform Event** from a59 trigger and have the ERP subscribe.60- **Outbound via Apex callout.** Trigger-time callouts are blocked61 (synchronous callouts from triggers aren't allowed). Use62 `@future(callout=true)` or Queueable with `Database.AllowsCallouts`63 for fire-and-forget; for transactional integration, the64 event-driven path is preferred.65- **Inbound from ERP.** REST or Bulk API loads, gated through66 `LegalEntity` scoping and validation.6768The anti-pattern: writing a synchronous Apex trigger that calls the69ERP REST API on every Order insert. It cannot work synchronously70(blocked) and even when async it tightly couples Salesforce71deployments to ERP availability.7273## Disambiguating RLM, CPQ classic, and Salesforce Billing7475| Term | Meaning |76|---|---|77| **Revenue Cloud** | Marketing umbrella; refers to RLM in modern docs |78| **RLM** (Revenue Lifecycle Management) | Native quote-to-cash, no managed package |79| **CPQ classic** | `SBQQ__` managed package; the predecessor to RLM Transaction Management |80| **Salesforce Billing** | `blng__` managed package; the predecessor to RLM Billing |81| **Subscription Management** | Older subscription billing product, distinct from both above |8283LLMs frequently conflate RLM Billing with the `blng__` package. They84are different products with different objects, different APIs, and85different upgrade paths. Confirm namespace before designing.8687## Recommended Workflow88891. **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.902. **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.913. **Plan multi-entity scoping early.** Decide LegalEntity count and granularity before any data model extension. Adding entities mid-flight is disruptive.924. **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.935. **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.946. **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.957. **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.9697## What This Skill Does Not Cover9899| Topic | See instead |100|---|---|101| Declarative CPQ classic configuration | `omnistudio/cpq-classic-config` |102| CPQ-classic specific quoting patterns | `architect/cpq-architecture-patterns` |103| Subscription Management (legacy) billing patterns | `architect/cpq-architecture-patterns` |104| ERP-side connector implementation | `integration/named-credential-patterns` |
PranavNagrecha