7 secret migration pitfalls from Product Console to Product Designer

7 secret migration pitfalls from Product Console to Product Designer

Salesforce Industries is discontinuing 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 what migration pitfalls to expect. And how to avoid them.

Want to learn more about Salesforce Industries? Then read our blog, "What is Salesforce Industries?".

To get started, you can read through the manual https://help.salesforce.com/s/articleView?id=ind.comms_deploy_industries_cpq_in_lwc.htm&type=5. But note that there are manuals for all versions. We discovered that there are still many things that are not in the manual that need to be fixed. In this article, I'm going to share my experience and give best practices for a smooth Product Designer process.

Pitfall 1: problems with VlocObjAttrsFields

In the Product Console, we had the attributes assigned to products, but not individually to the layout. We viewed the attributes using the custom view called "VlocObjAttrsFields."

I discovered that custom views are not supported in 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 custom representation of VlocObjAttrsFields, but assign directly to the design time layout.

Pitfall #2: Missing layouts

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

EXPERT ADVICE:

Make sure you make all the changes in Git. But now that we've migrated to the product Designer, it's 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 specifications

I was already a bit concerned about this, but while preparing for the migration I noticed that we needed to fix this. Quite a few of our products had attributes assigned to them that were not assigned to the implemented object type specification. We probably forgot to add those to Git.

EXPERT ADVICE:

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

Pitfall 4: obsolete min and max validation of attributes of type number

During the testing phase, we found that some product pages would not load. After much debugging, we found out that we were using an old validation method for number (& currency) attributes.

After consultation with support via case and assistance from Carlos Alonso Rodriguez we became aware that this functionality had been discontinued as of 2017. We could not do much, ignoring the fact that the product designer did not work for these products. This will become an issue with the introduction of the new LWC Cart, which also does not support min/max validation.

EXPERT ADVICE:

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

• Using Context Rules. We found out that this would not work because it does not support validation on line items
• Advanced Rules. This might work, but we found out that there is still an unresolved idea about the exchange of ideas that prevents this:https://ideas.salesforce.com/s/idea/a0B8W00000J5aEoUAJ/min-max-validation-for-attributes
• Apex, using the ProductValidationInterface. This is what we ended up doing, pretty straightforward, 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 for this idea on the IdeaExchange: https://ideas.salesforce.com/s/idea/a0B8W00000J5aEoUAJ/min-max-validation-for-attributes

After clearing the ValidValuesData__c field, we solved our problem and the product pages reloaded.

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

This was not a big problem before, but we had strange issues that we could not clear up. But with the help of this nice SFDX plug-in https://www.npmjs.com/package/@casenine/sfi-healthcheck we found out that we had some data problems. Some attributes were not made applicable to the object type Product2. After fixing this problem, many issues of this have been fixed.

Pitfall #6: Attribute categories not suitable for products

We had problems where we could not link the attributes to the product layouts at design time.

EXPERT ADVICE:

We found the cause of these problems because the fields vlocity_cmt__ApplicableTypes__c were not set to the value Product2 and the same for vlocity_cmt__ApplicableSubType__c was not set to the value Product attribute. After we fixed this, we were able to add the attributes to the design time layout.

Pitfall #7: Products without Record type

During the migration, we discovered that all of our products had no record type assigned to them.

EXPERT ADVICE:

After making the Product2 record types available to the appropriate profiles and permission sets, we repaired the products, assigning the vlocity_cmt__Product record type to all products.

Theodore's conclusion

Hopefully, after reading this, you will still want to migrate to the new Product Designer. It may be a lot of work, but the reward is a new and user-friendly new Product Designer. In its current state, it will not replace the old Product Console, but for 80% of your work you should be fine with the Product Designer. I hope this article will help you have a successful migration to the new Product Designer. Want to learn more about OmniStudio FlexCards? Then read our blog: 'FlexCards: The Easy Way To Create Lightning Web Components' to learn more.

Curious for more? Subscribe to the Technical Deep Dive series today. 

Theodore van Donge

Tech Lead

Theodoor van Donge works at CaseNine as a Tech lead. In this capacity he is responsible for several projects at customers. Theodoor not only deals with the actual development and implementation, but also advises customers in the areas of process and strategy.