Explanation:

Telecommunications companies often operate with highly complex product catalogs, legacy systems, and intricate service fulfillment processes. As a result:

New hires—especially in sales, service, or operations—require deep understanding of configurations, systems, and customer flows
Onboarding programs can be lengthy and resource-intensive, especially without guided digital tools
Industries like telecom have historically struggled with knowledge silos and manual processes, increasing ramp-up times

This is one of the reasons why platforms like Salesforce Communications Cloud emphasize Guided Selling, process automation, and streamlined training assets to accelerate onboarding and reduce time to productivity.

Explanation:

In Salesforce Industries CPQ (Vlocity CPQ), Context Rules are used to determine:

Whether certain products should appear in the catalog
Eligibility of products
Dynamic pricing
Other rule-based logic tied to context (e.g. Account, Quote, Opportunity)

To achieve this, Context Mappings link data in the org (like fields on sObjects) to the context used by the Rules Engine.

✅ What goes in the source expression?
✅ A. The API name of an sObject field → Correct

In a Context Mapping:
The Source Expression is the API name of the field you want to evaluate.

This tells the Rules Engine:
“When evaluating this rule, fetch this value from this field.”

For example:

If you want to evaluate the Account’s Segment:

Source Expression = Segment__c

Or if using a standard field:

Source Expression = Industry
This is how the Context Rule Engine retrieves values for rule evaluation.

Why the Other Options Are Incorrect
✅ B. %%field%% → Incorrect
That’s syntax for document templates, not for context mappings.

✅ C. {{field}} → Incorrect
This is Handlebars/Mustache syntax used in templates—not context mappings.

✅ D. A calculated formula used by the context rule service engine → Incorrect
You cannot directly enter complex formulas in the Source Expression field.
The field expects an API field name.
Any calculations must be performed either:
Before rule execution

In the rule’s filter logic, not in the source expression itself.

Explanation:

In Salesforce Industries (Vlocity) CPQ, Promotions are used for time-bound or targeted discounts/incentives, while Offers are more permanent product bundles or recommendations.

When to Use a Promotion Instead of an Offer?
A. Limited Customer Set → Promotions can target specific segments (e.g., VIPs, geographic regions).

C. Limited Time Availability → Promotions are ideal for seasonal/urgent deals (e.g., Black Friday discounts).

D. Quick Sales Boost → Promotions drive urgency (e.g., "Limited stock at 20% off").

Why Not the Others?
B. B2C Customers Only → Offers and promotions can both target B2C/B2B; this doesn’t dictate the choice.

E. Product Cost Increasing → Pricing adjustments (e.g., price rules) handle this, not promotions.

Explanation:

The Vlocity Cards Framework (now part of OmniStudio under Salesforce Industries) is the foundation for creating FlexCards, which are dynamic UI components used to present data in context across desktop, mobile, and portal experiences.

Here's what it provides:

✔️ Cards These are the actual FlexCards, which display summarized or detailed information—like customer profile snippets, account balances, or order details.

✔️ Layouts Layouts define how multiple cards are displayed on the page (e.g., vertical stack, horizontal tabs, or custom arrangements). You can create responsive UIs without heavy custom code.

✔️ Templates Templates offer reusable HTML/CSS structures for cards—controlling look and feel such as styling, spacing, and behavior like modals or drill-downs.

Together, these empower non-developers to quickly build modular, context-aware interfaces with minimal coding.

❌ Why the Others Are Incorrect:
B. Cards and pre-built wizards ❌ “Wizards” (step-by-step UI flows) are part of OmniScripts, not the Cards Framework

C. Templates for ad-hoc promotions ❌ Promotion setup is handled via Product Console or Promotions framework, not through Cards

Explanation:

When you assign a time plan to a child product in a promotion:

It controls the duration of the promotional price for that specific child product.
The time plan does not affect the parent product or overall promotion expiration.

Example: A 3-month discount on a phone accessory (child) while the main device (parent) has no time limit.

Why Not the Other Options?

B. Incorrect → The promotion’s end date is set separately (not by child product time plans).
C. Incorrect → Customer eligibility is determined by qualification rules, not time plans.
D. Incorrect → Start times are configured in the promotion setup, not the time plan.

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:

This use case revolves around modifying a product’s attribute (Service Level) at runtime based on customer-specific data (Account.SLA = Gold). Here's why Context Rules with a context dimension are the way to go:

Context Rule → allows evaluation based on external or related object values (like Account fields).
Context Dimension → allows you to target the specific product line item (in this case, the Installation Service).
Context Mapping on Account.SLA → lets you reference that the customer has a “Gold” SLA.
Function to modify attributes → enables the rule to programmatically set the attribute value to “Full Service” on that line item.

It’s a perfect match for behavior that dynamically adapts configuration during the cart experience.

❌ Why the Other Options Fall Short:
A. Advanced Rule – Configuration + Modify Attributes ❌ Modify Attributes is not a valid product relationship type; Advanced Rules also don’t directly handle attribute mutation based on external data like Account.SLA

B. Context Rule + function to modify attributes ⚠️ Close, but missing the context dimension—needed to scope the change to the line item

C. Advanced Rule – Eligibility + Auto Add ❌ Eligibility rules determine what can be selected, not how attributes should be preset or mutated during selection

Explanation:

In Salesforce Industries CPQ (Vlocity CPQ), attributes on products can be:

Static → Defined at design-time and not editable during the selling process.
Dynamic (Run-time configurable) → Editable by the user during configuration in the cart.
The difference hinges on whether the attribute has the Run-time Configuration flag set.

✅ Run-time Configuration Flag → Correct
✅ This flag controls:

Whether the attribute appears in the Vlocity Cart configuration window for user input.
Whether sales reps or customers can change the attribute’s value while configuring products.

If Run-time Configuration = true:
The attribute appears as an editable field in the cart UI (e.g. dropdown, textbox).
The user can select or enter a value before adding the product to the cart.

Example:
“Speed” attribute → sales rep can choose between 50 Mbps, 100 Mbps, etc., in the cart UI.

If not checked:
The attribute value remains hidden or fixed behind the scenes.

Why the Other Options Are Incorrect
✅ A. Active flag → Incorrect
Determines whether the attribute is generally active and available in EPC.
Does not determine if it’s editable in the cart UI.

✅ C. Filterable flag → Incorrect
Allows the attribute to be used as a filter in catalog browsing or searches.
Unrelated to whether it’s editable in the configuration window.

✅ D. Not Hidden flag → Incorrect
While there’s a “Hidden” flag, it controls attribute visibility in the UI.
But it’s the Run-time Configuration flag specifically that enables editability, not just visibility.
An attribute might be visible but not editable if Run-time Configuration is false.

Explanation:

Time Plan vs. Time Policy in Salesforce CPQ/Vlocity:

Time Plan:
Defines the duration for which pricing or contractual terms apply (e.g., 12-month subscription, 30-day trial).
Specifies start/end dates, billing cycles, and proration rules.

Example: A 1-year SaaS subscription with monthly billing.
Reference: Salesforce CPQ Time Plans

Time Policy:
Governs behavioral rules for time-based scenarios (e.g., renewals, cancellations, grace periods).
Determines what happens when a time plan expires or is modified (e.g., auto-renew, terminate).
Example: "Auto-renew subscription 30 days before expiration."

Why Option D?
A time plan’s core purpose is to define how long pricing/terms are active (duration).

Why Not Other Options?
A (Proratable): Both plans/policies can involve proration, but this isn’t a defining difference.

B/C (Start Date Flexibility): Start/delay rules can apply to both; they don’t distinguish a time plan.

Explanation:

When you're building an unauthenticated, product discovery experience on a public-facing website—such as for a telecom brand—the goal is to display offers (products/services) without requiring login or cart creation. The Digital Commerce API layer is ideal for this use case.

Here’s why:

getOffersByCatalogCode allows you to:
Retrieve all active product offers from a given catalog
Include filtering criteria like categories or eligibility rules
Display product names, descriptions, prices, and media assets to anonymous users
It’s commonly used on “Shop Our Plans” or “Explore Our Services” public pages.

❌ Why the Other Options Are Not Suitable:
B. getCartsItems ❌ Requires a cart session → used for logged-in users managing cart contents
C. getOfferDetails ❌ Retrieves details of a single offer, not a catalog list → better for a follow-up click
D. getCartsProducts ❌ Also tied to an active cart context → not suitable for anonymous browsing

Explanation:

Let’s analyze the scenario:
Goal: Ensure the user returns to the page where they began the Guided Selling process.
In Salesforce Industries CPQ, the Guided Selling experience is often implemented using OmniScripts.

OmniScripts:
Are multi-step wizards
Execute server-side calls
Navigate between screens
Integrate with the Vlocity Cart

When a user finishes a Guided Selling flow, you typically want them to:
✅ Return to where they came from, such as:
Account page
Quote page
Home page
Custom dashboard
This is precisely the job of the done action element.

✅ E. done action element → Correct
The done action element in OmniScript:
Defines the navigation behavior when the script finishes.
Supports:
Redirect to a specific URL
Go back to the previous page
Stay on the same page
Example configuration:
Done Action → “Navigate back to the originating record page.”
This is the official way to ensure the user returns to where they started.

Why the Other Options Are Incorrect
✅ A. checkout → Incorrect
“Checkout” is part of cart operations, not navigation after OmniScript completion.

✅ B. postCartItems → Incorrect
Posts selected products to the cart.
Has nothing to do with page navigation.

✅ C. remote action element → Incorrect
Executes Apex or Integration Procedures.
Not responsible for navigation or returning the user to a previous page.

✅ D. selectables element → Incorrect
Displays lists of selectable products in Guided Selling.
Does not handle page navigation.

✅ F. set values element → Incorrect
Used to set data values in OmniScript’s JSON structure.
Does not manage navigation.

Explanation:

When executing a Move Order in Salesforce Industries CPQ (typically used when transferring services from one account/location to another), the Cart processes Asset-Based Ordering (ABO) operations. The action types for line items help indicate what will happen to each product or service involved in the move.

✅ A. Disconnect
Indicates that a product is being removed from the original account as part of the move.
The system marks this with actionCode = Disconnect for the source account’s asset.

✅ B. Existing
Marks the product or service as retained (carried forward) in the destination account.
Think of it as a "continuation" of service at the new account—hence, the tag actionCode = Existing.

❌ Why the Others Don’t Apply:
C. Change ❌ Refers to configuration updates (e.g., speed increase), not relevant to move orders
D. Suspend ❌ Used when temporarily pausing service—not part of standard move order logic