[Gilles Muys]

I did some basic investigation: in my RCA org, the Product Type field is editable for almost all profiles. However, it’s a pick list with only one value called “Bundle”. The only other possible value is BLANK.
Even with Salesforce Inspector, you can’t modify that field.

The picklist field is also defined as restricted, and you are not allowed to add your own pick list values to it.
This tells me that Salesforce has put additional restrictions on that field and that they don’t want us to be able to edit the field by design. I was able to confirm that fact via Google search.

[Gilles Muys]

@tsenko-aleksiev I was not aware of this annoying limitation.

Have you tried to update this Type field via data loader instead of trying to do it directly in the UI? Sometimes, such limitations are UI-driven and they don’t apply to the data model itself.

[Gilles Muys]

Hi @kim-draeger-arries , I have seen similar situations in the past. There is no problem using MDQ with pricing injected from price rules. Your current rules might work just fine with MDQ without making any MDQ-specific adjustments.

Just remember that bundles (virtual or not) cannot be segmented.

Also, since you are talking about setting the “List Price”, make sure your rules triggers before the internal calculation steps (price waterfall calculation). There would be an exception with out-of-the-box block pricing but since you mention that you are using custom logic for that, you might be just fine.

You can do a quick validation in a sandbox for potential adjustments: just enable one product for MDQ (create a price dimension on it), and check if your current pricing logic yield the correct pricing on your quote.

Hope this helps!

[Gilles Muys]

Hi Kim,
As an FYI, I moved your post to this forum.

Swapping out products directly in subscription records is against best practices, or at least unconventional! The normal process is renew the prior product into a different product (using the Renewal Product field on the Product record, or by modifying the renewal quote manually as appropriate for the transaction), or by doing an amendment, cancelling the prior product and quoting the new one.

If you have no choice but to proceed with a subscription’s product swap, there are a few things you need to be careful about in my opinion:

• Only swap the product in the currently active subscription, i.e. do not touch terminated subscriptions
• Verify if you need to do the product swap in all revised subscriptions as well as the original subscription. Since you say that your company does not use amendments, this does not apply to you obviously, but it might be useful information for others reading this post!
• Consider whether or not you need to do the same product swap in the original quote that generated the subscriptions you are about to modify. Indeed, if your subscription is linked to a specific source quote line, the CPQ renewal engine will go back to that original quote line in addition to the subscription being renewed for some pieces of data
• If you do proceed with swapping the product in the original quote line, your original quote will be recalculated. So make sure there is no price impact when swapping products!
• The prior 2 comments might also apply to order products, if you use the CPQ order management functionality.
• If the subscription with the swapped product has an associated Subscribed Asset, any use of that subscribed asset record will be impact since the Subscribed Asset has a reference to the subscription (but not to the product itself). This might impact reports and dashboards for example, but also potential integrations with other systems.

There might be other subtleties in making these product swap changes. Make you test thoroughly in a sandbox before going live with your process.

[Gilles Muys]

Hi @rachel-linder , I have not done this in a long time but if I remember correctly, the filter needs to be defined on the custom lookup field itself. That field being defined on the Product Option object, you will be limited in how you can filter, based on the other fields available on the Product Option object. For example, the Quote object is not available to the Product Option in the data model, so you won’t be able to use any Quote-related context for the filtering.

If filtering is not feasible due to such constraints imposed by Salesforce, you might have to use a validation rule instead, in order to guarantee a correct configuration of your bundle.

[Gilles Muys]

Revenue recognition is dependent on how you define your performance obligations, per ASC606 regulations.

For most one-time products, the performance obligation is achieved when the product is delivered/fulfilled. For example, a physical product might be considered delivered when it leaves your warehouse, a.k.a. when it is shipped. More technically speaking, the performance obligation is achieved when there is a transfer of property from you to your client.

CPQ does not provide revenue recognition functionality by itself. It’s a downstream consideration that possibly start at the end of the fulfillment process or at time of invoicing. From that perspective, it does not matter if a product is a subscription product or a non-subscription product converting into an asset.

[Gilles Muys]

Hi Rachel, just like many other fields on the Product object, the Salesforce Billing fields are twinned (copied) from the Product record to the Quote Line record at the time you add the product to the quote.

Changing the fields on these 5 products (Product2 object) will have no effect to existing quote lines.

You can either remove such products from existing quotes and add them back, now with the correct data, or run an update query directly on the quote lines, targeting the correct quotes/quote lines of course.

Remember that because such an update query will change quote line data, you need to run this update with a batch size of 1 to prevent governor limits.

[Gilles Muys]

You are correct. Using quote line groups allows you to specify a different term for each group, using Start Date and either Subscription Term or End Date. The QLE will automatically calculate the number of segments within each group.

[Gilles Muys]

Hey Aleksander, I have seen this use case. You can create a custom formula field on the Quote line that returns SBQQ__ProductOption__r.SBQQ__Feature__r.Name. Then you should be able to use that custom field in your price conditions. Obviously, your price rule needs to target the Calculator for this to work!

[Gilles Muys]

This is a fairly common use case actually. At the end of the day, you need to determine how data entry will be done between using multiple fields (street address, city, zip/postal code, state/province, country), or a single field which could be a text area field, or a lookup to an Account (or a custom object) that represents the delivery location.

Once you have made that first determination, it’s time to think about some automation since you are using MDQ. It’s not user friendly for example, to ask the sales rep to re-enter the same address on each segmented quote line. There are 2 ways to address this:

1. Use a virtual bundle as the parent of your segmented product. You might need a separate bundle for each segment product. You would specify the delivery location on this virtual bundle, and a simple price rule can propagate that field value to its child segment quote lines
2. Use the QCP to propagate the location specified in segment 1 to the other segmented lines

I personally favor the first approach, as it provides a consistent way of specifying the delivery location for both segmented and non-segmented products. My other preference is to use a lookup field to an account or potentially a custom object, rather than a text area field or a set of fields for the address. That makes it easier to re-use the same delivery address across multiple quotes. On the other hand, the record for the lookup object must exist before you work on your quote.

[Gilles Muys]

The article you reference confirms my own investigation. The field is uneditable by design. Strange choice from Salesforce, IMHO!

[Gilles Muys]

Thanks @gaurang-patel . That is something I will definitely explore. It seems to address some limitations from the prior Ramp functionality.

[Gilles Muys]

You just confirmed what I was suspecting, and you found a pretty good way to address the separate orders between the cancel and replace parts of such transactions. At the cost of additional complexity and customization.

[Gilles Muys]

Thanks @gaurang-patel for sharing your story. Indeed, you point out some common scenarios that have limited support with the Cancel & Replace package and therefore the need for its customization. MDQ is definitely adding layers of complexity across the board, despite being a really powerful tool for ramp and escalator deals.

How do you feel about the fact that the Cancel & Replace package is separating the Cancel part and the Replace part in two separate opportunities and quotes?

[Gilles Muys]

Yes, that’s the expected behavior. I usually create a custom field that I add to the Calculating Fields fieldset, and make sure every loaded quote gets a unique value in it, such as a datetime field that you set to TODAY(). Once the load is complete, you can delete that custom field, unless of course you execute such loads on a regular basis.

And you are correct, product rules targeting the Calculator will not execute if triggers are disabled.