How to avoid these 7 secret Migration Pitfalls from Product Console to Product Designer

How to avoid these 7 secret Migration Pitfalls from Product Console to Product Designer

Salesforce Industries is retiring the use of AngularJS which will slowly but surely be phased out. As a result, we are migrating from the old Product Console to the new shiny Product Designer. Theodoor van Donge, Lead Software Engineer at CaseNine, knows which migration pitfalls you can expect. And how to avoid them.

To start, you can begin your journey by reading the manual located at  https://docs.vlocity.com/en/Deploy-Industries-CPQ-in-LWC.html. But watch out, there are manuals for all versions. We discovered that there are still a lot of things not covered by the manual, which need to be fixed. In this article I’m going to share my experience and I’m giving best practices for a smooth Product Designer process.

migration

Pitfall #1: Problems with VlocObjAttrsFields

In the Product Console we used to have the attributes assigned to products, but not individually to the layout. We viewed the attributes using the custom view called “VlocObjAttrsFields”. 

Screen Shot 2022 07 26 at 2.33.37 PM

I discovered that custom views are not supported within the Product Designer. Therefore we had to manually assign all attributes and fields to the design time layouts for the Product Designer.

EXPERT ADVICE:

My advice is not to use the VlocObjAttrsFields custom view, but assign directly to the design time layouts to start with.

Pitfall #2: Missing design time layouts

During the migration we found out that for some of our products we were missing design time layouts. Probably they were created but we forgot to push them to Git.

EXPERT ADVICE:

Make sure you commit all changes to Git. But now we migrated to the product Designer, it is important to get this right. So we created the layouts manually for those products that were missing a layout.

Pitfall #3: Attributes assigned to Products but not to object type specs

I was already a bit worried about this, but while doing the preparation for the migration I became aware we had to solve this. Quite a few of our products had attributes assigned which were not assigned to the implemented object type spec. We probably forgot to add those to Git. 

EXPERT ADVICE:

You can manually analyze which products and attributes are broken, but luckily we have made a SFDX Plugin to easily analyze this for you https://www.npmjs.com/package/@casenine/sfi-healthcheck.

Pitfall #4: Deprecated min & max validation of number type attributes

During the testing phase we found out that some of the product pages wouldn’t load.. After a lot of debugging we found out that we were using an ancient method of validation for number (& currency) attributes.

Screen Shot 2022 07 26 at 2.34.45 PM

After discussion with support via a case and the help of Carlos Alonso Rodriguez we became aware this functionality was deprecated from 2017 on. Not much we could do, ignoring the fact the Product Designer wasn’t working for these products. This will become a more problematic issue with the introduction of the new LWC Cart, which won’t support the min/max validation either.

EXPERT ADVICE:

So we had to obviously solve this. We discovered a few solutions:

  • Using context rules. We found out this wasn’t going to work as it doesn’t support validation on line items
  • Advanced Rules. This could work, but we found out there is still a unresolved idea on the idea exchange preventing this: https://ideas.salesforce.com/s/idea/a0B8W00000J5aEoUAJ/min-max-validation-for-attributes
  • Apex, using the ProductValidationInterface. This is what we ended up doing, quite straight forward, easy to build with some knowledge of Apex.

If you also liked the simplicity of the old min & max validation please support us and vote on this idea on the IdeaExchange: https://ideas.salesforce.com/s/idea/a0B8W00000J5aEoUAJ/min-max-validation-for-attributes

After emptying the ValidValuesData__c field we fixed our problem and the product pages loaded again:

migration

Pitfall #5: Attributes assigned to Products and/or object type specs but not to the design time Product2 Object Type

This wasn’t a big problem before, but we had strange issues we couldn’t clarify. But with the help of this nice SFDX plugin https://www.npmjs.com/package/@casenine/sfi-healthcheck we found out we had some data issues. Some attributes were not made applicable to the Product2 Object Type. After fixing this issue a lot of problems were solved.

Pitfall #6: Attribute categories not suited for products

We had issues where we couldn’t connect the attributes to the design time product layouts. 

EXPERT ADVICE:

We found the origin of these problems in that the fields vlocity_cmt__ApplicableTypes__c not on Product2 value was and same for vlocity_cmt__ApplicableSubType__c not on Product Attribute value was. After fixing this we could add the attributes to the design time layout.

Pitfall #7: Products without Record type

During the migration we found out that all of our products didn’t have a record type assigned.

EXPERT ADVICE:

After making the Product2 record types available for the right profiles and permission sets we fixed the Products, where we assigned the vlocity_cmt__Product record type to all products.

Theodoor’s Final Verdict

After reading this, hopefully you still want to migrate to the new Product Designer. It  can be a lot of work, but the reward is a new and easy to use new Product Designer. In the current state it will not replace the old Product Console, but for 80% of your work you should be good with the Product Designer. I hope this article will help you to do a successful migration to the new shiny Product Designer. Good luck!

Discover more in depth information about Salesforce Industries solutions here or contact us directly for more information about successful CPQ implementations. 

Theodoor van Donge
Author // Theodoor van Donge

Theodoor van Donge is Lead Software Engineer at CaseNine. In this capacity, he is responsible for various CPQ implementations at customers, including energy supplier Engie. In addition to his involvement in the actual development and implementation of CPQ solutions, Theodoor also advises customers in the areas of process and strategy. In doing so, he uses his substantive expertise and practical knowledge.

Didn’t find what you were looking for?

Follow us on Social Media

Enjoying the blog?

Transform your Salesforce Application into a CPQ solution.

Receive the latest CPQ, Energy and Telecom blogs straight to your inbox. Disrupt competition with Salesforce industries and integrations.

 

Subscribe to our Blog today!