#Salesforce Revenue Cloud40 personnes en discutent

When refreshing developer sandboxes where core configuration data like products, catalogs, attributes, price books, and price rules do not carry over, you should leverage reliable data migration utilities such as Salesforce Data Loader, SFDX data tools, or specialized CPQ seeding scripts. To maintain parent-child hierarchies and prevent duplicate records across environments, ensure that you prepopulate and maintain consistent external IDs across all catalog and pricing records before executing bulk data inserts. 

For your deployment workflow moving from development to downstream environments, cleanly divide your tasks by deploying metadata components like context definitions, expression sets, and decision tables via VS Code first, while using integration platforms like Dell Boomi to handle your underlying pricing data records. Following a strict sequence that deploys your metadata structure prior to your pricing data records ensures that dependent references resolve correctly from the start. 

Execute essential post-deployment steps to prevent runtime calculation issues such as "Price Not Found" errors. You must refresh your decision tables, synchronize pricing data, and trigger product index rebuilds in the target environment so that runtime calculations align properly against your newly deployed context definitions and catalog hierarchies.

When refreshing Developer sandboxes, core configuration data like Products, Catalogs, Attributes, Price Books, and Price Rules do not automatically carry over. To seed this data efficiently, you should use data migration tools like Data Loader, SFDX data CLI commands, or specialized CPQ data migration utilities. To preserve parent-child relationships and avoid duplicate keys, maintain consistent External IDs across environments for all catalog and pricing records before performing bulk data inserts. 

For your deployment workflow from Dev to downstream environments, split your tasks cleanly between metadata and configuration data. Use VS Code and your metadata pipeline to deploy Context Definitions, Expression Sets, and Decision Tables, while using data migration or integration tools (such as Dell Boomi or data loaders) for price books and pricing rules. Follow a strict deployment sequence by deploying metadata components first, followed by your pricing and catalog data records. 

Finally, execute the necessary post-deployment steps to prevent runtime errors like "Price Not Found." You must refresh Decision Tables, synchronize pricing data, and rebuild Product Indexes in the target environment so that runtime calculations resolve correctly against the newly deployed context definitions and catalog hierarchies.

Hi @Dhaval Shah

,  

There are out-of-the-box migration paths to de-risk and accelerate CPQ to RevCloud migrations: 

I hope that helps. 

Hi @Ayush Negi, 

Please refer below: 

https://help.salesforce.com/s/articleView?id=000381216&type=1

https://help.salesforce.com/s/articleView?id=ind.qocal_considerations_syncing_quotes_and_opportunities_in_revenue_cloud.htm&type=5

No, natively, ARM/Revenue Cloud doesn't let you search and add from "all products" the way Salesforce CPQ does..  

Natively, there's no way to search and add products in the Transaction Line Editor without going through Browse Catalog, and Browse Catalog is inherently catalog scoped; a product has to be catalog/category assigned to be searchable and addable there.  

For comparison: in Salesforce CPQ, clicking Add Product on the QLE pulls up a list of products based on your price book — there's no catalog concept in CPQ, so effectively every priced product is visible and pickable.

In ARM, Browse Catalog replaces that flow, and it's built around the catalog/category model by design — a product needs catalog assignment (plus price book entry, selling model, and indexing) to appear there.

Hi Marie,

The line editor doesn't read the currency off the screen. It prices with whatever CurrencyIsoCode actually arrives in the context the procedure runs with. If that value comes through blank, pricing falls back to the corporate currency, and a GBP quote still grabs the EUR price book entry.

A few things keep doing this even after the currency is set on the procedure.

Check the quote itself, not the opportunity. If the quote was created while the opp was still EUR, the quote stays EUR.

Existing lines keep the price book entry they were added with. Switching the quote to GBP doesn't swap those. Reprice them, or drop a new line on and see if that one comes in as GBP.

Product discovery and the line editor can be calling a different procedure than the one you edited. Trace a GBP quote and look at the pricing input before it picks an entry. If it already says EUR there, the mapping that ran never got the quote currency.

When the trace shows GBP going in and you still get the EUR entry, then the price book on that quote doesn't have a GBP entry for that product, and it's falling through.