#Revenue Cloud84 人がディスカッション中

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 @Rohit .

For this requirement, I would use a Record-Triggered Flow with a Scheduled Path on the Contract. 

Approach:

•  Schedule the path for 30 Days Before → Contract End Date. 
•  At that time, check whether a renewal Opportunity already exists. 
•  If not, use Create Records to create the Renewal Opportunity and notify the Account Owner. 
•  To prevent duplicates, maintain a Renewal Opportunity lookup or a Renewal Created checkbox on the Contract and check it before creation. 

Flow: 

 Contract → Scheduled Path (30 Days Before End Date) → Duplicate Check → Create Renewal Opportunity → Notify Account Owner 

Hope This Helps!!

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.