Explanation:

Root entity context scopes define the primary business object from which a CPQ process is launched. The key scopes are Opportunity (for new sales), Quote (for configuring a proposal), and Contract (for renewals). These entities contain the line items that are evaluated by CPQ logic.

Correct Options:

B. 🎯 Opportunity
The Opportunity is a fundamental root entity context scope. Many CPQ processes, like generating initial quotes and calculating roll-up summaries, are initiated from and operate within the context of an Opportunity, which represents a pending sale.

C. 💰 Quote
The Quote is a primary root entity context scope. Pricing rules, product rules, and calculations are most commonly evaluated within the context of a specific quote, as it is the central document for configuring and proposing a deal.

F. 📝 Contract
A Contract can serve as a root entity, especially for renewal scenarios. When generating a renewal quote, the existing contract provides the context for the products, terms, and pricing that need to be considered.

Incorrect Options:

A. ❌ Order
An Order is not a root entity context scope. It is typically a downstream system of record created after a Quote is accepted. CPQ calculations and rules are not evaluated from the Order context.

D. ❌ Asset
An Asset is not a root entity context scope. While assets are important for renewal processes and can be referenced within a quote line's context, they do not serve as the root starting point for CPQ calculations.

E. ❌ Account
An Account is not a root entity context scope. While account fields can be referenced in rule conditions for targeting or pricing, the CPQ process itself is not initiated from an Account record.

G. ❌ Product
A Product is not a root entity context scope. The Product object contains definitions, but the contextual evaluation of rules and calculations happens on a Quote, Opportunity, or Contract that contains those products as line items.

H. ❌ Order Line Item
An Order Line Item is not a root entity context scope. It is a child of an Order. CPQ logic is applied at the quote level before an order is ever created.

Explanation:

When dealing with bundles in Salesforce Industries CPQ, you have two primary pricing strategies:

✅ 1. Parent-Priced Bundles
The parent product carries the entire price of the bundle.
All child products are priced at $0 (zero price).
The price of the bundle does not vary based on the selection of child products unless adjustments are explicitly configured.
This simplifies pricing for fixed bundles.

Example:
Bundle Product → “Mobile Data Plan”
Parent price = $50/month
Child products = $0 (included)

✅ 2. Summed Pricing (Component Pricing)
Each child product carries its own price.
The bundle price = sum of all child products’ prices.
Flexible for “build-your-own” or configurable bundles.

Example:
Parent → “Internet Plan”
Modem Rental → $10/month
Speed Upgrade → $5/month
Total bundle price = $15/month

✅ Option A is Correct
✅ Price the child products as zero and assign a flat rate to the parent product.
This is a textbook example of parent-priced bundles in Industries CPQ.

Why the Other Options Are Incorrect
✅ B. Use multiple price lists to assign more than one price to a product → Incorrect
That’s a technique for multi-region or multi-currency pricing, not specifically for bundle pricing.

✅ C. Change the display text of a price list entry to show the starting price → Incorrect
Changing display text affects how prices are shown to users, but it’s not a pricing method for handling bundles. It’s purely cosmetic.

Explanation:

✅ Correct Option: A. Products can be set as non-assetizable
Assetization is the process in Salesforce Industries CPQ where a product or service is converted into a customer asset upon order completion. This allows for a record of what a customer owns, which is essential for future activities like service, support, or order modifications (e.g., upgrades or downgrades). However, not all products need to be tracked as assets. For instance, one-time charges like an "installation fee" or "shipping cost" are not recurring and don't represent a long-term service or good. In Salesforce Industries CPQ, you can flag a product with the "IsNotAssetizable" field to ensure it is not converted into a customer asset after an order is fulfilled.

❌ Incorrect Option: B. Existing customer assets must be marked as assetizable
Existing customer assets are, by definition, already assetized. They have already been converted from an order line item into an asset record. The "assetizable" flag is a product setting that determines whether a product will become an asset in the future, not a property of an asset that has already been created.

❌ Incorrect Option: C. Setting a product as not assetizable ensures that the product is offered as a promotion to customers
The "IsNotAssetizable" flag has no direct connection to promotions. It is a technical field that controls whether a product creates a corresponding asset record upon order fulfillment. Promotions are typically managed using a separate set of features, such as promotions, discounts, or special pricing rules. A product can be non-assetizable and not be a promotion, and a product that is a promotion can be assetizable (e.g., a "promotional subscription").

Summary:
The question focuses on the concept of assetization in Salesforce Industries CPQ, which is the process of creating a record of a customer's purchased products or services. The correct statement identifies that not all products are meant to be tracked as assets, and the platform provides a way to prevent this through a specific configuration setting.

Reference:
Salesforce Help: Assetization and Activation in Industries Order Management

Explanation:

In Salesforce Industries CPQ (Vlocity), when you need to evaluate Order Line Items—especially for compatibility across selected products or services—Advanced Rules with type Configuration Validation (Compatibility) are the right tool.

These rules allow evaluation of relationships between products and services, such as:

“Product A cannot be sold with Product B”
“If Product C is selected, then Product D must be included”
“Only one item from Group X is allowed per order”

They operate after product selection, validating selections inside the Cart or Order Line Items against compatibility logic, making them perfect for use cases that depend on how items coexist in the cart.

Why Other Options Don’t Apply:
B. Context Rule – Qualification ❌ Used to determine product eligibility in a catalog or basket—not for validating order line items
C. Advanced Rule – Eligibility ❌ Determines whether a product is eligible for display/selection—not compatibility after selection
D. Advanced Rule – Availability ❌ Controls time or geography-based availability, not post-selection validation of line items

Explanation:

When a user opens the Vlocity Cart, the platform needs to determine which products to display in the catalog. The rules engine processes various rules in a specific order to progressively filter and validate products.

Here’s the correct sequence:

✅ 1. Context Rule – Qualification
✅ This is the first rule type processed.

Determines whether a product should appear in the catalog for the customer.
Filters products based on:
Account attributes (e.g. segment, region)
Opportunity data
Customer eligibility for specific offers

Example:
“Only show B2B internet plans for accounts with Segment = Enterprise.”
If a product fails a qualification rule, it’s never shown in the catalog at all.

✅ 2. Advanced Rule – Eligibility
Runs after qualification.
Further filters products based on:
Product-specific eligibility conditions
Dynamic product attributes

Example:
“This mobile plan is only eligible for customers over 18 years old.”

✅ 3. Advanced Rule – Availability
Determines whether a product is available based on:

Inventory
Location-specific constraints
Serviceability

Example:
“Fiber internet is only available in specific zip codes.”

✅ 4. Advanced Rule – Configuration Validation (Compatibility)
Runs last.
Validates compatibility among selected products in the cart.
Ensures no conflicting combinations exist once products are added to the cart.

Example:
“If Product A is selected, Product B cannot also be selected.”
Compatibility checks don’t run until products have been chosen and configurations exist.

Why the Other Options Are Incorrect
✅ B. Advanced Rule – Availability → Incorrect
Processed later in the chain—not first.

✅ C. Advanced Rule – Eligibility → Incorrect
Runs after qualification rules.

✅ D. Advanced Rule – Configuration Validation (Compatibility) → Incorrect
Runs last, during or after product selection in the cart.

Explanation:

Correct Option ✅: A. createCart method
The createCart method is required to initialize a shopping cart session before products or configurations can be added. Without this method, no cart context exists, making it impossible for Guided Selling to function. It ensures that subsequent operations such as price association and product selection are tied to a valid cart instance.

Correct Option ✅: B. Associating the cart with a valid price list or price book
Every cart must be tied to a valid price list or price book so the system knows which prices to apply for selected products. Guided Selling relies on this association to correctly calculate and display pricing in the cart. Without it, products may appear but won’t have valid pricing data.

Correct Option ✅: C. HTML Template for horizontal or vertical mode
The Guided Selling cart requires a rendering layer that defines how products and categories are displayed. HTML templates in either horizontal or vertical mode provide this structure. They enable a user-friendly, step-by-step selling experience that’s consistent across the cart. Without this, the cart cannot visually present options to the user.

Correct Option ✅: D. Associating the cart with a valid account
A cart must be linked to an account so billing, entitlements, and applicable product offerings can be validated. Guided Selling uses account associations to determine eligibility rules, discounts, and valid configurations. If no account is associated, the cart cannot be processed in a real-world business context.

Incorrect Option ❌: E. Associating the cart with valid user profiles
While user profiles control overall system access, they are not specifically required for building a Guided Selling cart. The cart relies on account and price list associations instead. Linking to user profiles is a broader Salesforce security feature, not a direct Guided Selling configuration step.

Incorrect Option ❌: F. Multiple price lists for filtering product categories
Guided Selling does not require multiple price lists. In fact, a single valid price list per cart is sufficient. Filtering of products and categories happens through rules, attributes, and catalog configuration rather than multiple price lists. Multiple price lists could cause conflicts in pricing logic.

Incorrect Option ❌: G. Linking getCartItems to the template
The getCartItems API is not the required method in Salesforce Industries CPQ; the system uses getBasketDetails for retrieving cart contents. Linking getCartItems would be ineffective since it is not a supported or recognized call. This makes the option invalid for Guided Selling cart construction.

Summary 📝
To build a Guided Selling cart, you must establish a cart session using the createCart method, associate it with both a valid price list and a valid account, and provide an HTML template to control how the selling flow appears. Other options like user profiles, multiple price lists, or unsupported API calls are not necessary. These four requirements create the foundation for a functioning Guided Selling cart in Salesforce Industries CPQ.

Reference 🔗
Salesforce Help: Guided Selling and Cart APIs

Explanation:

In Salesforce Industries CPQ (Vlocity CPQ), product life cycle management is critical. Products have various date fields that determine:

When they can be offered for sale
When they’re no longer sellable
When they’re fulfilled or end-of-life

One visual clue in the Cart UI is the fifed (flagged) dock icon (sometimes displayed as a small alert or calendar icon) next to a line item. This icon indicates:

✅ The product’s Selling End Date is approaching or has passed.

✅ Selling End Date
Controls the last date a product can be sold.
Once the Selling End Date passes:
The product is no longer eligible for new orders.
Users may receive warnings or errors in the Cart.
The UI flags these products so sales reps know they’re about to go off-market.

Example:
Selling End Date = July 15
Today’s date = July 10
→ Cart shows an icon next to the product line to warn the rep.

Why Other Options Are Incorrect
✅ B. End of Life Date → Incorrect
End of Life Date indicates when a product is no longer supported or maintained by the business.
It doesn’t directly determine selling eligibility or appear as a flagged icon in the cart.

✅ C. Fulfilment Start Date → Incorrect
Indicates when fulfillment can start (e.g. service activation date).
Does not affect whether a product is sellable.

✅ D. Selling Start Date → Incorrect
Defines when a product becomes available for sale.
If it’s before the Selling Start Date, the product won’t appear in the catalog at all.
There’s no icon to indicate a product is “not yet sellable” in the cart.

Explanation:

Correct Option: 🟢 B. To ensure the cart continues to appear between process steps
Guided Selling in Salesforce Industries CPQ requires a persistent cart to maintain the cart’s state across multiple process steps. This ensures that users can seamlessly navigate through the guided process, adding or modifying products, without losing cart contents between steps. The persistent cart supports a continuous user experience, preserving selections as the user progresses through the OmniScript-driven flow.

Incorrect Option: 🔵 A. To prevent the regular Vlocity Cart from appearing
Guided Selling does not aim to prevent the regular Vlocity Cart from appearing. Instead, it enhances the cart experience by guiding users through a structured process. The persistent cart ensures continuity within Guided Selling, not suppression of the standard cart. The regular cart may still be accessible outside the guided process, making this option incorrect.

Incorrect Option: 🟡 C. To launch the OmniScript from the Vlocity action button and begin the process
While OmniScript powers Guided Selling, the persistent cart’s role is not to launch the OmniScript or initiate the process. The cart maintains product selections across steps, not triggers the process start. The Vlocity action button may invoke the OmniScript, but this is unrelated to the cart’s persistence, which focuses on retaining cart data throughout the process.

Incorrect Option: 🟠 D. To fully display the instructions and step titles for each process step
The persistent cart is unrelated to displaying instructions or step titles in Guided Selling. These are managed by OmniScript’s user interface components, which control the presentation of steps and guidance. The cart’s role is to preserve product selections across steps, not to handle UI elements like instructions or titles, making this option incorrect.

Summary
This question tests understanding of Guided Selling’s functionality in Salesforce Industries CPQ, focusing on the persistent cart’s role. The cart ensures continuity of product selections across multi-step processes, enhancing user experience in telecom or other industry configurations. Misunderstanding its purpose could lead to incorrect assumptions about UI or process initiation, critical for CPQ developers.

Reference
Salesforce Industries CPQ Documentation

Explanation:

In Salesforce Industries CPQ, when configuring Product Rules or Price Rules that use Advanced Rules with entity filters, you often need to evaluate Product Attribute values to determine if a rule should be triggered.

Entity Filter Context:
Entity filters allow you to filter records based on related entities (like Product, Quote, Account) and their fields or attributes.

Evaluating Product Attributes:
Product Attributes are custom fields on the Product object. To evaluate them in an entity filter, you must specify how the attribute value should be evaluated.

Role of "Evaluation Criteria":
This field on the Entity Filter record defines the logic or criteria used to evaluate the attribute value. It essentially tells the rule engine, "How do I want to assess this attribute?" Examples include:
Equals
Not Equal To
Greater Than
Is Null
Contains

Without setting the Evaluation Criteria, the system does not know what condition the attribute value must satisfy for the filter to pass.

Why the Other Options Are Incorrect:

A. Entity Filter Type
This defines what type of entity you are filtering on (e.g., Product, Quote Line, Asset). While necessary for setting up the filter's scope, it does not define how an attribute's value is evaluated.

C. Formula for Conditions
This is used for more complex logic where you might write a Salesforce Formula (similar to a validation rule formula) to evaluate a condition. While powerful, it is not the required field specifically for evaluating a product attribute value on a standard entity filter. The basic entity filter uses the Evaluation Criteria field for the operator.

D. Attribute Lookup Field Name
This refers to the field that holds the attribute value you want to evaluate (e.g., a field API name). This is certainly required to identify which attribute to evaluate, but it alone is insufficient. You must also set the Evaluation Criteria to define the condition (e.g., equals, not null).

Reference:

In the Entity Filter configuration in Salesforce CPQ Advanced Rules, the key fields are:
Field: The attribute or field to evaluate (e.g., Product__r.My_Attribute__c).
Evaluation Criteria: The operator (e.g., Equals, Not Equal To).
Filter Value: The value to compare against.

The Evaluation Criteria is a mandatory component to define the condition's logic when evaluating any field or attribute value.

Conclusion:
To evaluate a product attribute value, you must specify the condition logic via the Evaluation Criteria on the Entity Filter. Therefore, the correct answer is B. Evaluation Criteria.

Explanation:

Promotions are used in Salesforce Industries CPQ to deliver targeted, time-limited, or segment-specific incentives such as special pricing, discounts, or restricted eligibility. They are ideal for conditional and temporary offers rather than permanent product rules or penalties.

Appropriate Use Cases

B. The product's price should change based on the customer type
Promotions support segment-based pricing (e.g., different prices for B2C vs. B2B or enterprise vs. SMB) using eligibility or context rules tied to Account attributes.

C. The product should only be available to B2C customers
Promotions can restrict eligibility or visibility to specific segments (e.g., B2C only) through rules that evaluate Account Type, Record Type, or custom fields.

E. Special pricing should only be available for a limited time
Promotions include built-in Start Date and End Date fields, making them perfect for temporary offers like flash sales, seasonal discounts, or promotional campaigns.

Why the Others Are Not Appropriate

A. Cancellation penalties
Cancellation penalties are managed via Pricing Rules, Pricing Adjustments, or contract logic — not Promotions.

D. “Sell quickly”
This is a business or marketing goal, not a configuration use case handled by Promotions.

References

Salesforce Trailhead:
Learn About Promotions and Discounts in CPQ — Covers time-bound offers and customer-segment targeting

Salesforce Trailhead:
Industries CPQ Promotions — Explains creating promotions for limited-time pricing and eligibility rules

Explanation:

In Salesforce Industries CPQ (Vlocity), Configuration and Validation Rules are used to enforce logical product relationships during cart or order configuration. These rules ensure that customers can only select valid combinations of products and services. The three supported product relationship types are:

1. Requires
The Requires relationship enforces dependency between products. If a customer selects one product, another product must also be included.
Example: Selecting a mobile data plan requires a SIM card or a base subscription.

Purpose: Prevents incomplete or invalid configurations by ensuring all necessary components are present.

2. Excludes
The Excludes relationship prevents incompatible products from being selected together.
Example: A premium internet package excludes the ability to select a basic internet package simultaneously.
Purpose: Avoids conflicts and ensures customers do not purchase overlapping or contradictory services.

3. Recommends
The Recommends relationship suggests complementary products when a product is selected.
Example: Adding a smartphone to the cart may recommend accessories such as a protective case or insurance plan.
Purpose: Supports upselling and cross-selling strategies without forcing customer choices.

Why Other Options Are Incorrect

Optional:
Not a formal relationship type; optionality is inherent in product selection.

Limited Quantity:
Managed via inventory or quantity constraints, not product relationship rules.

Suggests:
Not a defined relationship type; “Recommends” is the supported term.

Not Compatible:
This is essentially covered by Excludes, not a separate relationship type.

References
Salesforce Industries CPQ Developer Guide – Product Relationships in Configuration and Validation Rules
Salesforce Developer Documentation
Salesforce Help – Industries CPQ Product Relationships Overview
Salesforce Help Documentation

Explanation

The remote method postCartItems is a core API call used in the Salesforce Industries CPQ (formerly Vlocity) application. Its function is to take a selection of products and physically add them as line items to the current active Quote or Order object (the "Cart"). It facilitates the transition of selected products from the available catalog into the transactional cart list.

Why other options are incorrect

A. Filters products for the cart
Product filtering is handled by different mechanisms like Context Rules or API methods such as getProducts with specific filters, not postCartItems.

B. Submits the order
Submitting the order is a distinct process handled by an API like submitOrder or checkout, which typically happens after all items are already finalized in the cart.

C. Puts the items in the selectables list
Items are in the "selectables list" (the available catalog) before being added to the cart. postCartItems moves them out of the selectables view and into the cart view.

E. Moves the order to the next stage
Order movement between stages is part of the Order Management process, managed by different API calls or workflow configurations that occur after the cart interaction is complete.