Explanation:

In a Guided Selling OmniScript within Salesforce Industries CPQ, the Selectable Items element plays a key role in presenting product options to users based on predefined filters and logic. It’s designed to dynamically display products that match user selections or context criteria.

✅ Correct Answers:

A. Retrieves filtered products from the product catalog
The element uses filters (often passed via Integration Procedures or remote actions) to query the product catalog and return only relevant items.
This ensures users see a curated list based on their needs or eligibility.

B. Lists products retrieved by the remote action
After the remote action (e.g., getCartsProducts) fetches the filtered products, the Selectable Items element renders them in the UI for selection.
It acts as the visual layer that displays product cards, images, and pricing.

❌ Why the Other Options Are Incorrect:

C. Invokes the remote method postCartItems
This method is used after selection, typically to add items to the cart — not by the Selectable Items element itself.

D. Stores the filters for the products to be retrieved
Filters are usually passed via Integration Procedures or DataRaptors, not stored in the Selectable Items element.

Explanation:

When viewing an Order record under the Orders tab in Salesforce Industries CPQ, the system provides two distinct layers of status tracking by default.

Why "C" and "D" are Correct
Salesforce Status (C)
This is the standard, out-of-the-box field on the Salesforce Order object (API name: Status). It represents the high-level business lifecycle of the record, such as Draft or Activated.

Salesforce Industries Order Status (D)
This is a custom field added by the Industries package (API name: vlocity_cmt__OrderStatus__c). It provides more granular visibility into the Order Management process. For example, while Salesforce Status might show "Activated," the Industries Order Status could indicate "In Progress," "Completed," or "Cancelled" based on the actual fulfillment logic.

Why Incorrect Answers are Wrong

A. State of tasks within an Orchestration Plan
Task statuses (such as Running, Completed, or Failed) are important for fulfillment monitoring but are only visible within the Orchestration Plan View or on individual Orchestration Item records. They are not displayed as primary status fields on the Orders tab.

B. State of the Orchestration Plan itself
The overall status of the Orchestration Plan (e.g., In Progress) is accessible when you click into the related Orchestration Plan for the order. It is not part of the default fields on the main Order header.

E. PONR Status
Point of No Return (PONR) is a milestone used to restrict changes or cancellations after a certain stage in fulfillment. While critical for order management, it is typically tracked via a checkbox or field on Orchestration Items and is not one of the two primary status fields shown by default on the Order header.

References
Salesforce Help: Order Management Overview
Vlocity Documentation: Industries Order Management Guide explaining synchronization between Salesforce Order Status and vlocity_cmt__OrderStatus__c
Trailhead: Explore Order Management for Industries

Explanation:

In Salesforce Industries (Vlocity) CPQ, Vlocity Picklist definitions include many configuration and metadata fields, but not all of these fields are exposed or visible at runtime during order capture in the Vlocity Cart.

Only fields that are explicitly designed for runtime usage and required for user interface rendering and selection behavior are surfaced in the cart and OmniScript experience. Many other fields exist purely for design-time configuration and are not intended for runtime display.

Why this is true (key concepts)
Picklist definitions contain a mix of developer configuration fields, backend metadata, and runtime-relevant values such as labels, values, and defaults. For performance, stability, and security reasons, the cart consumes only the subset of data necessary for runtime behavior. This separation between configuration metadata and runtime data is intentional and is commonly tested on the exam.

Why B. False is incorrect
Choosing False would imply that every field in a picklist definition is visible at runtime. This is incorrect because exposing all configuration and metadata fields would reveal unnecessary internal details, negatively impact performance, and break the intended separation between design-time setup and runtime execution.

Key Exam Tip
When you encounter statements such as “All fields are visible at runtime” or “Every configuration field is exposed,” approach them with skepticism. Salesforce Industries CPQ intentionally separates design-time metadata from runtime data to ensure efficient and reliable user experiences.

Explanation:

In Salesforce Industries CPQ (formerly Vlocity CPQ), Document Templates used for generating quotes, contracts, proposals, or order documents support conditional inclusion of sections. This allows documents to be dynamically tailored based on the specific products selected and the business context.

Document sections within a Vlocity Document Template can be conditionally included based on two main items:

A. Products
You can associate one or more products or product bundles directly with a template section. The section is included in the generated document only if those products exist in the cart, quote, or contract line items. This is commonly used for product-specific clauses, terms, or addendums, such as including a Broadband Terms section only when an internet service product is selected.

B. Advanced Entity Filters
For more complex conditions, entity filters or Advanced Entity Filters can be applied to a section. These filters evaluate data on the quote, contract, order, account, or related line items, such as account type, opportunity stage, custom fields, or attribute values. If the filter condition evaluates to true, the section is included; otherwise, it is excluded. In the Document Template Designer, you can enable Use Advanced Entity Filters and link or define the appropriate filter.

This approach enables highly tailored document generation, such as including a section only when a specific product is present and additional business rules are satisfied.

Why the other options are incorrect

C. Merge codes
Merge codes are placeholders used to insert data into a document, such as {{!Quote.Name}}. They control what data is displayed within a section but do not determine whether the section itself is included or excluded.

D. Browser Version
Browser version has no impact on document template conditional logic. Document generation is server-side and independent of the client browser being used.

Reference
Salesforce Help documentation on conditionalizing sections using entity filters explains how Advanced Entity Filters control section inclusion. Additional Salesforce Help resources on Vlocity Web Templates and the GetConditionalTemplateSections interface describe associating products or filters with template sections. Trailhead modules on Industries CPQ Document Generation also demonstrate conditional section inclusion using products and filters.

Explanation:

The requirement is to set prices based on configurable service attributes such as Bandwidth (1 GB versus 10 GB) and Network type (Internet versus External). This scenario directly matches the definition of Attribute-Based Pricing, where pricing is determined by the selected product attributes.

D. Correct (Attribute-Based Pricing)
To meet this requirement, the developer would configure an Attribute Pricing Matrix, or a Range Attribute Matrix for the numeric Bandwidth attribute. Each row in the matrix defines pricing outputs for a specific combination of attribute values, for example:

Row 1: Bandwidth = 1 GB, Network = Internet → Monthly Price = $10, One-Time Price = $5
Row 2: Bandwidth = 10 GB, Network = External → Monthly Price = $20, One-Time Price = $0

This approach ensures the correct price is automatically applied based on the customer’s configuration choices.

Why the other options are incorrect

A. Usage Pricing
Usage Pricing is intended for consumption-based charging, such as a cost per unit of usage over time (for example, $0.10 per GB consumed). In this case, pricing is fixed based on selected service tiers rather than variable usage, so Usage Pricing is not appropriate.

B. Context rules for pricing adjustments
Context Rules are used to enforce product relationships such as Requires, Recommends, or Excludes. They do not define base pricing based on attribute selections. Pricing adjustments typically apply discounts or surcharges on top of an already determined base price.

C. Cost and Margin Pricing
Cost and Margin Pricing focuses on internal cost structures and profitability calculations. It is not a customer-facing pricing mechanism driven by configurable product attributes, making it unsuitable for this scenario.

Key Indicator
When the price of a product depends directly on configuration choices or attribute values, Attribute-Based Pricing is the standard and correct solution.

Reference
Salesforce Industries CPQ documentation on Attribute-Based Pricing describes this method as setting prices based on product characteristics or attributes, which aligns exactly with the scenario described.