#Salesforce Revenue Cloud35 discutindo

Example: Lets says 

A parent product named : A which is a bundle type product. 

It consist of a child product named : B which is also a bundle type product. 

B product contains a child product named C which is a standalone Product. 

Now, here A is the main parent , B is the parent and child of A and C is the child of B and grandchild of A. 

So, in CML my requirement is like. I need to fetch the whole cardinality of A which includes quantity of B and C.

Here are the short answers to your questions:

1. Salesforce CPQ and Agentforce Revenue Management, formerly Salesforce Revenue Cloud, can coexist in the same environment. However, they cannot and should not be used on the same opportunity for functional and technical reasons. Think of CPQ and ARM as two similar but completely independent products; there is no "Easy Button" for migrating from CPQ to ARM, especially with a "very developed" and highly customized CPQ implementation.
2. In some cases, but not all, you can reuse products, price books, price book entries, etc. Orders are used by both products. Whether configurations are reusable depends on whether they are platform-based or CPQ-specific. Bundle parents and their components will almost certainly need to be recreated for technical and sometimes functional reasons.

This sort of question is best answered live. I am happy to offer a free 30-minute consultation if you would like to discuss it. You can view my availability and schedule a time with me here: https://calendly.com/garvensconsulting

Or, if you prefer, you can watch or listen to this episode of my podcast, 

RevOps Roundtable, where I discuss this: Migrating from Salesforce CPQ to Agentforce Revenue Management

You can learn more about me and my business, Garvens Consulting, here: 

https://garvensconsulting.com/

 Hi @Vishal Verma

Thanks for your response. 

I checked everything you mentioned, and all settings are in place. 

I identified the issue: I had enabled “Transaction processing for quotes and orders” but had not selected a transaction type. 

I resolved it by: 

1. Creating a transaction type and selecting it under Revenue Settings.
2. Creating a new quote, since only new quotes can be updated with a transaction type.
3. Testing the rule, which worked as expected.

Hi @Swati Malkar

 Yes, Salesforce Spiff provides an Archive User option, but it is different from permanently deleting a user.

If a user has already been uploaded and added to Spiff, you can archive them by following these steps:

1. Go to Admin → Users in Salesforce Spiff.
2. Open the user’s profile.
3. Click Edit.
4. Deselect Make this user visible.
5. Confirm Archive User and save.

After archiving:

• The user will no longer appear as an active user in the regular Users page.
• Data syncing is automatically disabled.
• Existing statements and historical records are retained.
• The user cannot be assigned to new teams or plans.

If the user is synced from Salesforce or another external source, you should also review the source system and syncing settings.

Important: Archiving hides the user from active management, but it does not permanently delete their historical data. For complete permanent deletion, check your organization's Spiff data-retention policies and available Salesforce support options.

Reference: Archive and Unarchive User Accounts

Hope this helps! 😊  

If you find this response helpful, please mark it as the Accepted Answer, as it may also help other Trailblazers facing a similar issue. 😊  

Hi Kamakshi,

Ramp segments can be auto-generated on amendment and renewal quotes when the ramped assets and ramp configuration meet the supported Revenue Management behavior. Salesforce documentation specifically lists auto-generated ramp schedules for renewal quotes.

I would first verify that:

• The original contract/assets were created with a supported ramp structure.
• The renewal is being initiated through the standard Renew Assets process.
• The required Ramp Deals settings are enabled.
• The asset state periods and dates are correctly maintained.

If the renewal quote is still being created without the expected ramp segments after these checks, could you share the renewal process/action being used and a little more detail about the contract/asset setup? That would help determine whether this is a configuration issue or an unsupported scenario.

Salesforce also documents that ramped assets have specific renewal limitations and considerations.

Hi @Swati Malkar

This is a known pain point in Spiff/ICM the tool is calculating off a live field (

Root cause: Spiff's plan logic is likely referencing Opportunity.CloseDate (or a similarly live-synced field) to bucket the deal into a payout period. When that field changes after calculation/payout, any report or re-run that re-evaluates the deal picks up the new value, creating a mismatch between "period paid" and "period the deal now says it belongs to." 

How to actually fix it a few layered options, roughly in order of how I'd sequence them: 

1. Snapshot the period at calculation time, don't derive it live. Add a dedicated field something like Commission_Period__c on the commission/statement record (or in Spiff's own statement object) that's set once when the statement runs and never recalculated from CloseDate again. Spiff does support adding effective dates on plans/logic and locking historical statements, so this should be a config change in Spiff's plan design rather than custom Apex — check that "lock historical statements" setting is actually turned on for closed periods.
2. Separate "Close Date" (sales-facing, editable) from "Commission Effective Date" (finance-facing, locked once a statement is generated). Reps and deal desk need to edit Close Date for pipeline/forecast reasons that's normal. The commission engine should never read that same field for historical periods once paid.
3. Treat post-payout edits as a reconciliation event, not a silent recalculation. If a close date changes after a statement already paid against it, that should trigger a clawback/adjustment workflow (a new adjustment line in the next period), not a retroactive rewrite of March's numbers. This is standard ASC 606-adjacent practice Spiff's audit-ready expense reporting is built around exactly this kind of compliant, locked-period model.
4. On the Salesforce side, if Opportunity edits are what's causing this, consider a validation rule or Flow that blocks/flags Close Date changes on Opportunities that already have a Commission_Statement__c (or equivalent) linked and Closed/Locked at minimum, notify Finance/RevOps rather than letting it happen silently.

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.