Agentforce Revenue Management (ARM, formerly Salesforce Revenue Cloud) has dozens of org-level settings.
The documentation tells you what each one is – not what it does to your model: which toggle changes how prices calculate, which one decides what flow fires when a rep clicks Create Order, and which one can never be switched off once you turn it on.
That gap is where go-live goes wrong. Most production behavior in ARM is decided in Setup, not in code. This cheatsheet groups the settings that matter for go-live, says what each one actually does to your model, and – just as important – flags the few you can never take back.
ARM is moving fast. More teams are migrating off legacy CPQ, Salesforce keeps shipping new capabilities across pricing, transaction management, and orchestration, and the implementations that go smoothly all share one trait: they treat settings as architecture decisions, not admin tasks.
The lesson most teams learn the hard way is that Revenue Cloud problems rarely start in code. They start in Setup.
So before enabling anything, three rules hold:
Each layer depends on the one before it. Enable top to bottom, and validate each against a real scenario before moving down:
Context Definitions and catalog indexing sit alongside steps 4-5 but live outside Revenue Settings.
Pricing procedures that depend on context data, context-aware configuration, and Product Discovery won't run until the relevant context definitions are activated and the catalog index is built – treat these as prerequisites configured separately, not as toggles on this page.
The settings below are grouped by what they affect in your model – foundation, configurator, pricing, transactions, renewals – not by where they live in Setup. For each one, the same four questions decide go-live: what it controls, its default, when to change it, and what breaks if you get it wrong.
One split runs through the whole list. Some settings are set it and forget it – turn them on and move on. Others have to match your business logic – their default is a guess, and for most orgs it's the wrong guess.
These switch ARM on. Some of them are the irreversible ones, so they carry the most weight.
Enable Revenue Cloud Features is the platform-level switch that activates ARM while your license is active. It cannot be disabled afterward. Nothing else on this list works until it is on. Treat the sandbox-first rule as non-negotiable here: enable it, document what changes across quote, order, pricing, and approvals, run baseline smoke tests, then promote.
Before it will behave correctly, Enable New Order Save Behavior has to be active under Setup → Release Updates. Skip it and parent-order logic – validation rules, triggers, flows – may not run when order products change. The order save behaviour change is documented as a release update for exactly this reason; the developer reference covers how it affects triggers and flows.
Quotes and Orders are the next layer. Under Order Settings you enable Orders, Negative Quantity, Zero Quantity, and Enhanced Commerce Orders together.
The last one changes the math: with Enhanced Commerce Orders on, Total Line Amount becomes available and Unit Price becomes optional. If both are set, Total Line Amount wins as the final price; if only Unit Price is set, the total is Unit Price × Quantity.
That is a model decision, not a cosmetic one – know which field your downstream systems read before you turn it on.
! Note that Enhanced Commerce Orders can't be switched off once enabled, so it belongs in your irreversible list alongside Enable Revenue Cloud Features.
.png)
Configure Products at Runtime is required for the Product Configurator to work at all. It lets users configure products inside quotes and orders based on your Product Catalog Management structure – attributes, relationships, and configuration rules. Without it, there is no configurator.
The rules engine is the real decision. ARM's Product Configurator supports two:
The two are not mutually exclusive – an org can run both, routing simple product lines through BRE and complex ones through the Constraint Rules Engine. The mistake here is reflexively enabling CRE for everything; it earns its keep on complex models and adds overhead on trivial ones.
This is where defaults lie to you most often. Salesforce Pricing activates the engine; the catch is that the default pricing procedure has to be assigned in two places – Salesforce Pricing Setup and Revenue Settings – and they must match. After any change to a procedure, rule, or configuration, run Sync Pricing Data or the runtime keeps using the old definition.
The settings below are the ones that decide how pricing actually runs:
The honest caveat from the field: Price Waterfall Persistence is worth enabling for auditing because it stores the calculation logs you will want the first time a price looks wrong.
%20(1).png)
The inverse – Hide Price Refresh Notification – is the one to leave off. It cleans up the UI by removing the warning that pricing is stale, and in doing so removes the only signal a rep gets that the number on screen is outdated. Salesforce generally recommends keeping it disabled, and so do we.
Transaction processing for quotes and orders applies custom rules based on attributes like size and complexity – and it is another setting that can't be turned off once activated. Enable it only after operational readiness, migration planning, and a rollback-and-support strategy review. Validate every transaction type in a sandbox first.
The three core flows are set-it-and-forget-it as long as you don't need custom logic – keep the defaults:
If you do need custom logic, clone the template flow, rename it, edit, activate, and assign the matching runtime permission sets (Create Orders from Quotes, Assetize Order) to the users who run them.
As-Is Renewals suits stable subscription models with limited repricing. It is the wrong default for any model that applies systematic uplifts or index-based adjustments at renewal – there, it silently carries last term's price forward.
Customize Contract Pricing is the setting to reach for when contract-specific pricing logic is required. Both are "match your business logic" settings: their value is zero or negative until your renewal process is actually designed.
Once the core is stable, several capabilities layer on top. Each is set up outside the main Revenue Settings toggles and earns its place only when the matching process exists:
A few recur across implementations, and they cluster around the same root cause – a default that assumes a process the org doesn't run:
The most useful advice here isn't in the documentation: don't validate settings feature by feature. Test by business scenario – a real quote, configured, priced, ordered, renewed – because that's where the dependencies between them surface before a customer finds them.
There is no universal settings template that fits every org, and there never will be.
Success in ARM is less about enabling everything and more about enabling the right things, in the right order, against a process you have actually mapped. If you want a second pair of eyes on that mapping before go-live, that's a conversation we're happy to have.
Which ARM settings are irreversible?
Enable Revenue Cloud Features, Enhanced Commerce Orders, and Transaction processing for quotes and orders. All three are permanent once activated, with no rollback, so each belongs in a sandbox first and in production only after full validation.
Why isn't my pricing recalculating after I changed a procedure?
Almost always a missed sync. Run Sync Pricing Data under Salesforce Pricing Setup after any procedure, rule, or configuration change – until you do, the runtime keeps using the previous definition.
Should I enable Instant Pricing?
Enable it when you want prices to update on every line edit rather than only on save. Hold off if your pricing procedures are computationally expensive, since it triggers a recalculation on each change.
Do I have to choose between BRE and CRE?
No. Both can run in the same org. Route simple product lines through the Business Rules Engine and complex, high-volume models through the Constraint Rules Engine with CML.
What does Enhanced Commerce Orders change?
It makes Total Line Amount available and Unit Price optional on order items. If both are set, Total Line Amount is the final price; if only Unit Price is set, the total is Unit Price × Quantity.
What's the safest order to enable settings in?
Foundation first (permissions, Revenue Cloud Features, quotes, orders), then configurator, then pricing, then transactions and renewals – validating each against a real business scenario rather than in isolation.
.svg)
.png)
.png)
.png)
