#Revenue Cloud102 discussing

RLM and CPQ are not a 1-1 and you're not going to want to focus on moving stuff over on a field by field basis. You need to focus on intent

of the fields and what they accomplish. How you accomplish similar functionality in RLM will be very different compared to how you do it in CPQ. Example: Setting up a bundle in CPQ is creating an option record, while in RLM you go into that configurator screen the functions almost like a flow. Not a 1-1 process by any means but the resulting bundles can be identical.  

Cheers!

Update: I figured it out 😄

The issue wasn't with the Product Configuration Flow, Product Classification, assignments, or attributes.

The missing piece was on the Product itself:

Configure During Sale = Allowed/Enabled

Once I enabled Configure During Sale on the product, the Product Preview started working correctly.

Hopefully this helps someone else who runs into the same issue where:

• Product Classification Preview works ✅
• Product Preview fails ❌
• Error says the Product Classification isn't associated with a flow even though everything appears configured correctly

Thank you everyone!

@Jothish B S the standard osGenerateAndPreviewDocument component does not automatically take the response of any Integration Procedure action added earlier in the OmniScript and use it as token data. The generated document uses the JSON available to the document generation step, based on the template’s token mapping method.

Trailhead explains that document templates can use JSON input data, and that the Token Mapping Method controls how tokens are populated. It also says you can use OmniDataTransform or a custom class for that mapping. Reference: (Trailhead)

For your example token: {{Quote.QuoteNumber}} the JSON used by document generation must look like this:

{  "Quote": {    "QuoteNumber": "Q-0001",    "AccountName": "ABC Customer"  }}

If you have quote lines, the final JSON must also contain a repeatable array, for example:

{  "Quote": {    "QuoteNumber": "Q-0001",    "AccountName": "ABC Customer",    "QuoteLines": [      {        "ProductName": "Product A",        "Quantity": 2      }    ]  }}

Correction to do would be: don’t use an 

Extract Data Mapper as the final token mapper if your source is already the IP response JSON. Use a Transform Data Mapper to shape the IP response into the exact JSON structure expected by the Word template.

Also open the OmniScript preview/debug panel and check the Data JSON after the IP action runs. If the Quote node is not present at the root, or if it is nested under something like IPResult.Quote, your tokens will not resolve.

For server-side generation, Salesforce also documents an Integration Procedure pattern using DocumentServiceGateway.generateDocumentWithTokenData, which is more suitable when the IP is responsible for preparing the full token JSON. Reference: (Salesforce)

Decide the pattern:

Use standard LWC + OmniScript JSON if the IP output is stored in the OmniScript JSON exactly as the template expects.

Use server-side IP document generation if the IP should fully control token data and document generation.

The missing part is mapping the IP response into the exact token JSON consumed by document generation.

I have users with reduced permissions, and they only needed the "Product Catalog Management Viewer" permission set to see the Browse Catalogs button 

As per this page 

> Provides Sales Agents read access to Product Catalog Management objects and 

                APIs, and permission to browse products by using Product Discovery. 

To pass through values from Quote or Order into a (Dis)Qualification Rule you need a few extra bits 

- create a custom note in the ProductDiscoveryContext, for Quote 

- a new attribute, context tag and mapping for the field  

- some apex. 

The page here explains the apex part (pretty poorly, with no test class) 

This needs to be before your Product List screen element in a custom version of the Discover Products flow 

It's explained well by JMT here in his video and blog