Explanation:

In Vlocity (Salesforce Industries) CPQ, Vlocity Picklist definition fields are used to define the list of selectable options for attributes. However:

These picklist definition fields themselves are not directly exposed or visible to users during runtime (i.e., in the Cart UI during order capture).

What is visible are the attribute values rendered using those picklist definitions, not the actual fields that define the picklist structure.

So while picklists control the available choices, the picklist object fields are not shown in the runtime experience.

Explanation:

In Salesforce Industries CPQ, Guided Selling provides an intuitive, interactive interface that assists users (especially sales reps) in selecting the right products for customers by walking them through a series of steps and pre-configured logic.

Here's how each of the correct features fits into the Guided Selling experience:

✅ A. Summary of assets
The system can fetch and display previously purchased products or services using the GetAsset API or pre-integrated DataRaptors, helping reps identify upsell or cross-sell opportunities.

✅ B. Step-by-step process
At its core, Guided Selling is a multi-step UI built with OmniScripts, designed to collect preferences, show filtered product choices, and guide users through product selection.

✅ D. Automatic totaling
As users add products to the cart, totals are updated in real-time using pricing engines and remote methods like getBasketDetails, ensuring visibility of the running total.

✅ E. Ability to edit items
Through persistent cart behavior and configured buttons/components, users can modify quantity, attributes, or remove items right from the Guided Selling UI.

❌ Why the Other Options Don’t Apply:
C. Launch cart from account/order
Not a feature of Guided Selling itself. Cart launch happens via actions configured on Account, Opportunity, or Quote but isn't visible within Guided Selling UI.

F. Change the price book
Price book (or Price List) is set at cart creation, not something users typically modify during the Guided Selling flow. It’s usually handled by backend logic.

Explanation:

In Salesforce Industries CPQ, to configure a flat price bundle, you typically:

Set the parent product’s price to the total bundle price (Option D). This ensures the bundle appears as a single-priced item in the cart.
Zero out the child product prices (Option A). This prevents child products from contributing additional cost and keeps the bundle price fixed.

This approach is commonly used when:

You want to simplify quoting with a single price for a bundle.
You’re offering promotional pricing that hides individual component costs.
You’re using bundled product options or option pricing overrides to suppress child pricing.

❌ Why the other options are incorrect:

B. Change the child products that are not optional to zero
This is too narrow. You should zero out all child products, not just non-optional ones.

C. Change the price of the parent product to zero
That would make the bundle free unless child products contribute pricing—which defeats the flat price goal.

E. Do nothing, you can't create a bundle with a flat price
Not true! Flat pricing is a well-supported strategy in CPQ using bundled options and overrides.

Explanation:

In Salesforce Industries CPQ (formerly Vlocity CPQ), the CpqAppHandler class is used to manage various CPQ operations, including cart actions.

When you want to create an order from a cart, you use the postCart method. This method finalizes the cart and converts it into an order.

getCart — Used to retrieve an existing cart (not to create an order).
newCart — Used to create a new cart, not to post or submit it.
createCart — There is no createCart method in the standard CpqAppHandler.
✅ postCart — Used to finalize (post) the cart and create the corresponding order.

Explanation:

Execution Order at Runtime:
Context Rules run first to determine if and where other rules (like Advanced Rules) should execute.
Example: A Context Rule checks "Is the customer’s market = US?" before allowing a US-specific Advanced Pricing Rule to run.

Why Context Rules Go First:
They act as filters or gates, setting the scope (e.g., by geography, customer segment) for subsequent rules.
Advanced Rules (e.g., Pricing, Product) only execute if the Context Rules pass.

Why Not Advanced Rules?
Advanced Rules handle business logic (e.g., discounts, bundling) but rely on Context Rules to qualify their execution.