#Salesforce Revenue Cloud34 discussing

 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.

Hi @Christopher Strecker

, That's the missing piece. By assigning "Product Configurator API User" permission to my user, I was able to connect without any error. 

Hi @Uttej Cheedalla, 

A few things I would suggest checking: 

• Verify that the Context Definition Mapping is correctly mapped to the fields/attributes used in the qualification rule.
• Check whether the Lookup Table input values exactly match the values being passed at runtime.
• Make sure the correct Lookup Table is referenced in the Qualification Procedure and the procedure is active.
• If you're using a custom/extended context, verify that the mapping is configured as the default context mapping.
• Try running the Qualification Procedure using Simulation with a known product/input combination. This can help determine whether the issue is with the rule configuration or the runtime context.

Thank You.