Explanation

Telecommunications companies have traditionally faced long and complex onboarding processes for new hires due to:

Highly complex product catalogs (bundles, plans, add-ons)
Strict regulatory and compliance requirements
Multiple legacy systems and operational tools
The need for employees to understand end-to-end service lifecycles (quote → order → provision → bill)

Because of this complexity, onboarding new employees—especially sales, service, and support agents—has historically taken weeks or even months.

Salesforce Industries (Vlocity) solutions were specifically designed to address this challenge by:

Simplifying user experiences
Providing guided flows (OmniScripts)
Reducing training time with standardized processes

Exam Tip 📝

On the Ind-Dev-201 exam, watch for industry pain-point questions like this.
If the question mentions:

Telecom
Complexity
Training or onboarding challenges

👉 The correct answer is very often True.

Explanation:

When you define a Context Mapping, you are mapping a "Context Dimension" (a virtual variable like AccountStatus) to a real piece of data in your Salesforce org.

Mapping to Data:
The Source Expression field is where you specify the path to the data. This is typically the API Name of a field on a specific Salesforce object (sObject).

Relationship Traversing:
You can often use dot notation to traverse relationships. For example, if your mapping is based on the Order object, but you need the Account's region, your Source Expression might be Account.BillingState.

Context Scope:
The system uses this API name to query the record currently in the "scope" of the cart (e.g., the Quote, Order, or Account record) and feed that value into the Rule Engine for evaluation.

Analysis of Incorrect Answers

B. %%field%%
This syntax is commonly used in Vlocity Templates or some legacy email templates to represent merge fields, but it is not the correct syntax for a Context Mapping Source Expression.

C. {{field}}
This is the Handlebars syntax used extensively in Vlocity OmniScripts and FlexCards to reference data in the JSON data wrap. While used elsewhere in the platform, the Context Rule service expects the literal API name or path, not a merge tag.

D. A calculated formula used by the context rule service engine
While you can use "Function" as a mapping type for complex logic, the "Source Expression" field itself is specifically designed to hold the field path or API name. Formulas are typically handled within the Entity Filter logic or via a custom Function mapping, not as a standard text-based "Source Expression."

References
Salesforce Help: Context Mappings in Industries CPQ
Vlocity Developer Guide: Configuring Context Rules and Dimensions

Explanation

Promotions in Salesforce Industries CPQ are designed to be temporary marketing tools with specific, often narrow, constraints compared to standard product offers.

Limited Set of Customers (A)
Promotions frequently target specific customer segments (e.g., new customers only, loyal customers, or specific demographics). While general offers can also be targeted, the combination of customer targeting with time limits points strongly toward a promotion use case.

Available for a Limited Time (C)
This is the defining characteristic of a promotion. Promotions use Time Plans and policies to automatically start and stop offering special terms on a specific date, which isn't the primary function of a standard, ongoing offer or price list entry.

Needs to be Sold Quickly (D)
Promotions are used to create urgency, drive immediate sales volume, or clear inventory. They are tactical business tools for rapid market response.

Why Other Options Are Incorrect

B. Product is available only to B2C customers
This is an eligibility requirement based on a persistent customer type. This can be handled by standard Qualification Rules or Context Rules applied to a basic product offer, which are more permanent parts of the catalog setup than a temporary promotion.

E. Product cost is increasing
An increasing product cost would typically result in a permanent update to the base price list entry for a standard offer, not the creation of a temporary promotional configuration.

Explanation:

The Vlocity Cards Framework (now part of Salesforce Industries Lightning Web Components and the Digital Commerce/Industries CPQ suite) is a powerful, reusable UI framework designed to build flexible, data-driven, and highly customizable user interfaces for Industries applications (such as CPQ, Billing, Order Management, etc.).

It provides three core building blocks:

Cards
Reusable, self-contained UI components that display data from one or more objects (e.g., product cards, account summary cards, line item cards, etc.). Cards can be interactive and support actions like adding to cart or navigating.

Layouts
Define how multiple cards are arranged and organized on a page (e.g., grid, flex, tabbed, or custom layouts). Layouts control positioning, responsiveness, and overall structure.

Templates
Pre-built or custom structures that combine cards and layouts to create complete pages or sections (e.g., product catalog pages, cart summaries, account dashboards). Templates allow rapid assembly of complex UIs using drag-and-drop in Vlocity Build or OmniStudio.

This framework enables developers and administrators to create consistent, responsive, and scalable front-end experiences without heavy custom Lightning Web Component (LWC) development.

Why the Other Options Are Incorrect

B. Cards and pre-built wizards
While the framework supports wizards (via OmniScripts or guided flows), pre-built wizards are not a core part of the Cards Framework itself. Wizards are primarily handled by OmniStudio/OmniScripts.

C. Templates for designing ad-hoc promotions
Promotions are configured via the Promotions object and related rules (eligibility, context, pricing), not through the Cards Framework. The Cards Framework is for UI presentation, not for creating or managing promotions.

References
Salesforce Help: Vlocity Cards Framework Overview
→ "The Vlocity Cards Framework provides cards, layouts, and templates to build dynamic, data-driven user interfaces."
Salesforce Trailhead: Build User Interfaces with Vlocity Cards
→ Covers cards, layouts, and templates as the foundational elements of the framework.

Explanation:

In Salesforce Industries CPQ (Vlocity), Time Plans are used to define temporary pricing or discount schedules for products within a promotion. When you assign a Time Plan to a child product in a promotion, you are specifically controlling the duration and timing of the price change applied by that promotion.

Time Plan Function:
A Time Plan defines start date, end date, and potentially multiple phases (e.g., 50% off for first 3 months, then 25% off for next 3 months).
When linked to a product in a promotion, it dictates how long the promotional pricing or discount applies to that specific product.

Scope:
The Time Plan affects only the product(s) to which it is attached within the promotion—not the entire promotion or other products.
It allows for granular control over promotional pricing duration per product.

Why the Other Options Are Incorrect:

B. When the entire promotion expires
Incorrect. Promotion expiration is controlled by the promotion's own start/end dates, not by a Time Plan assigned to an individual product. A promotion can expire while a product’s Time Plan is still active (or vice versa).

C. Which customers are eligible for the child product
Incorrect. Customer eligibility is managed by Promotion Eligibility Rules or Targeting Rules, not by Time Plans. Time Plans control duration of pricing, not who is eligible.

D. When the time plan begins for the child product
Incorrect. While a Time Plan includes a start date (so it does define when it begins), this option is incomplete. The Time Plan affects both the start and end timing (the entire duration) of the price change, not just the start. Moreover, the core effect is the duration of the price change, not merely the start time.

Reference:
Salesforce Industries CPQ documentation states that Time Plans are used to “define the time periods during which a promotion price adjustment is in effect for a specific product.”
They are often used for introductory offers, limited-time discounts, or phased pricing (e.g., “$10/month for 6 months, then $20/month”).

Conclusion:
Assigning a Time Plan to a child product in a promotion specifically controls how long the price of that child product is changed by the promotion (Option A).

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 requirement is about automatically setting a product attribute value based on customer context (Gold SLA) at runtime.

Key Things the Exam Wants You to Recognize

The condition depends on Account data (Account.SLA)
The action is modifying a product attribute (Service Level = Full Service)
This must happen dynamically, when the product is ordered
That combination points directly to a Context Rule.

Why Context Rules Are the Right Tool
Context Rules are designed to:

Evaluate contextual data (Account, Cart, Order, Line Item)
Use context mappings (e.g. Account.SLA)
Invoke functions to take action, such as:

Modify line item attributes
Apply pricing logic
Control behavior dynamically

Option D correctly includes all required elements:

✔️ Context rule
✔️ Context dimension (line item)
✔️ Function to modify attributes
✔️ Context mapping on Account.SLA

Why the Other Options Are Incorrect

A. Advanced rule of type Configuration with Modify Attributes
❌ Advanced Rules are product-centric, not context-aware
❌ They do not reliably evaluate Account-level data like SLA

B. Context rule with a context mapping and a function
❌ Incomplete: it does not specify a context dimension
❌ The exam expects you to explicitly reference the line item dimension

C. Advanced rule of type Eligibility with Auto Add
❌ Eligibility rules determine whether a product can be selected
❌ Auto Add adds products — it does not modify attributes

Exam Tip 📝
Use this mental shortcut:
🧠 If the rule depends on Account / Customer data → Context Rule
🔧 If you need to set or change attribute values → Function (Modify Attributes)

If you see:
“When customer has X”
“Set attribute to Y”
“Based on account data”
👉 Context Rule with a function is almost always the answer.

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:

The Time Plan is the component that defines the "length" or "span" of the effect.

Duration Definition: It specifies a numerical value and a unit of time (e.g., 12 Months, 30 Days, 2 Years).
Pricing Impact: In a promotion, the Time Plan dictates exactly how long the promotional price override stays active for a specific product.
Static Nature: The Time Plan itself is just a bucket of time. It doesn't know when to start; it only knows how much time it contains.

Analysis of Incorrect Answers

A. A time plan is proratable: While pricing itself can be proratable based on subscription settings, "proratable" is not the defining characteristic that distinguishes a Time Plan from a Time Policy.

B. A time plan can start on the date of purchase: This is actually the responsibility of the Time Policy. The Time Policy defines the "Start Date" trigger (e.g., Purchase Date, Activation Date, or a specific Calendar Date).

C. A time plan's start can be delayed: Again, the "Start" logic (including any offsets or delays like "Start 30 days after activation") is configured within the Time Policy, not the Time Plan.

Explanation:

The scenario involves:
- A website for a communications company.
- Anonymous users (no login/authentication required).
- Need to retrieve products and display them for selection.

This is a classic browsing/catalog display use case, which aligns with the Digital Commerce API (part of Salesforce B2B/B2C Commerce) designed for storefront interactions.

Digital Commerce API vs. Cart-Based API:
Digital Commerce API: Used for storefront operations like browsing products, viewing details, searching, and managing guest sessions. It supports anonymous users.
Cart-Based API: Typically requires an active cart session (often tied to an authenticated user or a known cart ID). It focuses on cart-specific operations, not general product catalog browsing.

getOffersByCatalogCode:
- This method retrieves offers (products) from a specific product catalog.
- It is designed for anonymous access (no authentication required if the catalog is publicly accessible).
- Returns product information suitable for display on a website (name, price, images, etc.).

Why the Other Options Are Incorrect:
B. Cart-Based API - Get Cart Items (getCartsItems): Incorrect. This retrieves items already in a cart. Anonymous users at this stage are browsing, not managing a cart. Also, a cart may not even exist yet for an anonymous user.

C. Digital Commerce API - Get Offer Details (getOfferDetails): Incorrect. While this is part of the Digital Commerce API, it is used to get detailed information for a specific offer/product (after the user has selected one). The scenario is about retrieving products for display (listing), not fetching details of a single known product.

D. Cart-Based API - Get List of Products API (getCartsProducts): Incorrect. There is no standard getCartsProducts method in Cart-Based API. Cart APIs focus on the cart’s contents (getCartsItems), not on listing products from a catalog. Additionally, cart-based methods require a cart context, which anonymous users may not have initially.

Reference:
- Digital Commerce API methods like getOffersByCatalogCode are used in B2C/B2B storefronts to retrieve sellable items from a catalog for anonymous or logged-in users.
- In Salesforce Industries (Communications Cloud), offers represent marketable products/bundles.
- Anonymous user support is built into the Digital Commerce API via guest sessions or public catalog access.

Conclusion:
To retrieve products for anonymous users on a website, the correct method is getOffersByCatalogCode from the Digital Commerce API (Option A).

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