Create the QuoteLineItem with all required fields (Product, PricebookEntry, Quantity, etc.).
Call the PST API with pricing preference set to Force (or System) so pricing actually runs.
Handle the API response correctly.
Ensure the TLE/STLE component is on the page and RepriceAll is enabled in its action buttons.
Check that Hide Price Refresh Notification is turned off in Revenue Settings.
Hi everyone,
I'm currently working through the Trailhead module Implement Attribute-Based Pricing.
As part of the exercise, I updated the Default Pricing Procedure under Revenue Settings. After that, when I try to configure the product, I'm getting the following error:
"Something went wrong while running configuration rules. You can’t open the Product Configurator because the ConstraintEngineNodeStatus field either hasn’t been added to transaction line item objects or hasn’t been mapped to the active context definition. Your Salesforce admin can help with that."
Has anyone encountered this issue while following this Trailhead module? Could you please let me know what configuration I'm missing or what needs to be fixed?
Thanks in advance for your help!
#Trailhead Challenges #Revenue Cloud #Salesforce Revenue Cloud
Hi @Vasu Kasula, Please make sure Advanced Configurator is enabled, then add the ConstraintEngineNodeStatus mapping to the Context Definition.
Please refer below -
https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX00000TkvJb0AJ
Hello,
I am trying to complete this
module,and I am getting the following error:
We can’t find the quote Office Supplies. Make sure you create the quote for the EdgeMX account.
However, the quote has been created for the correct account and includes the products; I followed the content and challenge steps correctly.
I am also using a special Developer Edition org with Agentforce Revenue Management.
Can anyone help?
Thanks in advance.
#Trailhead Challenges #Trailhead #Revenue Cloud #Salesforce Revenue Cloud #Revenue Management System
Hello everyone,
Im having a issue where im unable to deploy between two orgs due to the error:
ExpressionSetDefinition │ SuraAutoGeneralSuraAutoGeneral │ Insurance isn’t a valid usageSubtype. Specify a valid usageSubtype for the DefaultPricing usageType and try again. │ ││ ContextDefinition │ extendedSuraInsuranceContext │ Cannot deploy Context Definition 'extendedSuraInsuranceContext' with release version '264.4.4' to an org with older release version '262.14.13'. This definition was created in a newer release and cannot be deployed to older orgs.
Both orgs, have Digital Insurance Packages and Salesforce Industries, where specifically the subtype of the orgs, despite them being the same "Insurance" wont let me deploy due the error previously mentioned.
Already went with support, and they told me to try deploying these components manually to a org which i dont have access to.
Also, having these orgs (Dev and build) with two different versions 264.4 and 264.11
Has anyone had a similar issue? Is there any other suggestions to try on this case?
Best,
#Salesforce Developer #Salesforce #Revenue Cloud
Anyone else running into recalculation headaches with Spiff/ICM when a deal gets reassigned to a different rep mid-period? Mine ends up double-counting or dropping the payout entirely, curious how others are handling ownership changes without breaking the calc.
#Sales Cloud #Revenue Cloud
We stopped using the current opportunity owner for the calc because that’s what caused most of the mess. Better to snapshot the credited rep when the deal closes and calculate from that. Then a later ownership change doesn’t move or duplicate an already earned payout.
Renewal Opportunity Creation Scenario: 30 days before a Contract expires, automatically create a Renewal Opportunity and notify the Account Owner. Questions: • Which Flow type would you use? • How would you calculate the 30-day window? • How would you prevent duplicate renewals?
Hi @Rohit .
For this requirement, I would use a Record-Triggered Flow with a Scheduled Path on the Contract.
Approach:
Flow:
Contract → Scheduled Path (30 Days Before End Date) → Duplicate Check → Create Renewal Opportunity → Notify Account Owner
Hope This Helps!!
The payout happened in the March commission run (that's when it was calculated and paid).
The deal's close date now shows February (because it was edited/backdated after the fact).
So there's a disconnect between when the money was actually paid (March) and what period the deal currently says it belongs to (February).
#Sales Cloud #Revenue Management System #Revenue Cloud #Salesforce Revenue Cloud
This is a known pain point in Spiff/ICM the tool is calculating off a live field (
Close Date) instead of a locked, point-in-time snapshot. The fix isn't really "how do I stop deals from being backdated" it's "stop letting a mutable CRM field drive an immutable financial record."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:
I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.
We're planning a large migration of legacy Asset records into Revenue Cloud and want to confirm we're not missing a bulk-friendly path.
We've confirmed HasLifecycleManagement, LifecycleStartDate/EndDate, and the underlying AssetStatePeriod object are all read-only via standard DML - Data Loader/Bulk API reject any attempt to write them (INVALID_FIELD_FOR_INSERT_UPDATE).
The only supported path we've found is the Connect REST API generate endpoint (asset-management/assets/actions/generate). It looks like a single-asset-per-call API with no bulk/batch equivalent, and the start date of the first asset state period is locked once the call completes.
Has anyone done a large historical Asset migration into lifecycle management this way? Curious about:
- Whether a bulk-friendly path exists that we're missing
- Realistic call volumes/patterns others have used against the generate endpoint
- Whether it's common practice to leave older/inactive assets non-lifecycle-managed and only onboard active ones
we did it using PST api. the approach here is to bulk create Order using PST and then activate the Order, it will create Asset lifecycle managed records automatically, this is will give audit history as well.
PST api supports bulk record creation (1500 records in a single api call).
Hi everyone,
I'm currently working on attribute-based pricing in Salesforce Revenue Cloud and came across a scenario I'd like some guidance on.
For example, I have an attribute called Color. If Color = Blue, I want to apply a 5% discount. This pricing rule should apply to every product in my product catalog.
Using Price Adjustment Schedules , the pricing adjustment is tied to a specific product. This works well for a small catalog, but in a large product catalog with thousands of products, creating and maintaining separate Price Adjustment Schedules for each product is time-consuming and difficult to manage.
Is there a way to define the pricing logic once and have it apply to all products instead of configuring it product by product?
I'd appreciate any suggestions or best practices. Thanks!
For something like this id recommend using the Pre hook to write the Attribute value say "Colour" to a "Colour" Field on the quote line.
You could then add into your pricing procedure to add a 5% discount if that colour field = "Blue"
We have one Bundle Product
with 10–15 unique child products (for example: iPhone 15, iPhone 16, Samsung, etc.).
We want to use
Attributes instead of Product Related Components and Product Component Groups
.
Requirement:
Question:
Can we achieve this functionality using Attributes only, where all child products are mapped through attributes and selected products are automatically added with the correct pricing, without using Product Related Components and Product Component Groups?
#Trailhead Challenges
You can definitely use the Constraint model to require products based on attribute selection. This is easiest if they are bundled together using the product related components.
To have them unbundled you would have to build a virtual quote in the constraint to be able to add other products and create the mappings in the constraint model.
I would suggest using a bundle and the product related components as it is going to be easier to manage in the long run. Ive found the constraint model to be finnicky and not fully developed
