Industries-CPQ-Developer Practice Test Questions

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

Explanation:

In Salesforce Industries CPQ (Vlocity CPQ), Time Policies and Time Plans work together to manage temporal pricing logic.

✅ Time Policy
A time policy defines how and when a time plan takes effect.

It controls:
Start behavior → when the time plan begins relative to order or contract dates
Proration behavior → if partial periods are charged
Alignment → e.g. align to billing cycle or contract start

In the context of promotions, the time policy determines:

✅ When promotional pricing applies to the customer account.

Example scenarios:
“Promo pricing begins immediately upon order activation.”
“Promo pricing starts on the customer’s next billing cycle.”
“Promo period begins 30 days after order date.”

Thus, the time policy governs the timing of when promotional prices actually kick in for the customer.

Why the Other Options Are Incorrect
✅ B. When the promotion starts → Incorrect
The “Selling Start Date” and “Selling End Date” on the promotion define when the promotion is available for sale in the catalog.
That’s different from the time policy, which dictates when the discounted pricing applies for a given customer.

✅ C. Which customers are eligible for the promotion → Incorrect
Customer eligibility is determined by:
Qualification rules
Context rules
Not by the time policy.

✅ D. Whether the customer can terminate the contract early → Incorrect
Early termination policies are governed by:
Contract terms
Cancellation penalties
Not the time policy itself.

Explanation:
In the Salesforce Industries (Vlocity) framework, Integration Procedures (IPs) are reusable, configurable workflows that handle integration logic. The naming convention often includes a suffix like VIP (Vlocity Integration Procedure).

While the name FetchAccountDetails might imply a read operation, in the Vlocity CPQ/OM data model and standard IPs, this specific Integration Procedure is typically responsible for both fetching and creating accounts as part of the order or cart lifecycle.

Here’s why:
Common Pattern:
The FetchAccountDetails IP is often designed with an “Upsert” pattern. If an account does not exist (for example, for a new customer during a guest checkout), it will create the account. If it exists, it fetches the details.

Context:
In e-commerce or CPQ flows, when a user proceeds as a guest or logged-in customer, the system needs to ensure an account record exists for the order. FetchAccountDetails handles this lookup and creation logic.

Standard Vlocity IPs:
Out of the box, FetchAccountDetailsVIP is the primary IP used during cart or order initiation to resolve the account, creating it if necessary based on input such as email, name, and other customer details.

Why the Other Options Are Incorrect:
A. updateAddressVIP – Incorrect.
This IP is responsible for updating address information on an account or contact, not for creating the account itself.

C. saveCartVIP – Incorrect.
This IP is used for saving or updating the cart and its items. It may reference an account but does not create one.

D. SubmitOrderVIP – Incorrect.
This IP handles the final submission and conversion of a cart into an order. By this stage, the account should already exist, having been created earlier in the flow, typically by FetchAccountDetails.

Reference:
In Salesforce Industries (Vlocity) template implementations, FetchAccountDetailsVIP is a core Integration Procedure used in the Order Management and Digital Commerce frameworks.

It typically includes data mapping steps that take input parameters such as customer email and name, then either query for an existing Account or create a new one using a subprocedure like CreateAccount.

Conclusion:
The Integration Procedure primarily responsible for creating accounts through its upsert logic is FetchAccountDetails (Option B).

Explanation:

When working with a very large product catalog (5+ million products) in Salesforce Industries CPQ, performance and maintainability are critical. The key is to use a rule that can apply globally without being attached individually to products.

Let’s break down each option:

❌ A. Qualification Rule
Used to determine product eligibility (whether a product can be shown or added).
Typically evaluated per product.
With millions of products, this becomes harder to manage and less performant.

❌ B. Evaluation Rule
Used to evaluate conditions after products are added to the cart.
Usually tied to specific products or offers.
Not ideal for catalog-wide logic.

❌ C. Advanced Rule
Very powerful but more complex to configure and maintain.
Typically scoped to specific use cases, not global catalog rules.
Overkill for a rule that needs to apply to everything.

✅ D. Context Rule
Applies at the transaction or cart context level, not at the individual product level.
Does not need to be associated with products, making it perfect for:
Very large catalogs
Global validations
Cart-wide logic
Best performance and simplest to implement for catalog-wide rules.

📚 Key Exam Concept to Remember
Context Rules are evaluated once per transaction and are not product-specific, making them ideal for extremely large catalogs.

This is a classic Ind-Dev-201 exam scenario:
Large catalog → avoid per-product rules
Need global logic → Context Rule

Explanation:

Let’s look at the scenario:

You want to take 20% off the price of a child product in a promotion.
This means you’re discounting the price relative to the product’s normal price.

✅ A. An adjustment → Correct
✅ In Industries CPQ, an adjustment is the correct tool for:
Applying discounts (percentage or fixed amount)
Increasing or decreasing prices
Adding surcharges

Adjustments can be defined as:
Percentage-based → e.g. “-20%”
Fixed amount → e.g. “-$5”
For your scenario:
Apply a -20% adjustment to the child product’s price inside the promotion configuration.

This ensures:
The base price remains stored in the system.
The system tracks the discount as a separate pricing element.

Example configuration:
Adjustment Type: Percentage
Adjustment Value: -20%

Why the Other Options Are Incorrect
✅ B. An override → Incorrect
An override completely replaces the original price with a new fixed value.
For example:
“Set the child product’s price to exactly $50.”
You don’t want to replace the price; you want to discount it by 20%.

✅ C. A price list → Incorrect
The price list defines:
Which products exist in a catalog
The base price of each product
You wouldn’t use the price list directly to apply a promotional discount.

✅ D. A price list entry → Incorrect
A price list entry:
Stores the base price for a product
It’s where the base price lives—but discounts should be handled separately as adjustments.
Overwriting the price in a price list entry would remove visibility into the discount mechanics.