Industries-CPQ-Developer Practice Test Questions

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

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:

Integration Procedures in Vlocity/Salesforce Industries:

Integration Procedures (VIPs) are reusable workflows that handle data operations (e.g., creating, updating, or fetching records).
They are commonly used in OmniScripts, DataRaptors, and Vlocity Cards to integrate with external systems or perform complex logic.

Why Option B (FetchAccountDetails)?
While the name suggests fetching account data, this VIP is also responsible for creating accounts if they don’t exist in the system.
It checks for an existing account (e.g., via an external ID) and creates a new one if no match is found.
Reference: Vlocity Integration Procedures Guide

Why Not Other Options?
A (updateAddressVIP) → Updates address records, not accounts.
C (saveCartVIP) → Saves cart data, unrelated to account creation.
D (SubmitOrderVIP) → Finalizes orders, typically after an account exists.

Explanation:

Scenario Requirements:

Large catalog (5M+ products) → Performance and scalability are critical.
Rule applies to all products → Needs to be efficient and avoid complex filtering.

Why Option B (Evaluation Rule)?
Evaluation Rules are designed to apply logic universally without requiring explicit product assignments.
They execute at runtime (when products are loaded) and evaluate conditions dynamically.
Best for large catalogs because they don’t rely on static mappings (unlike Qualification or Advanced Rules).

Why Not Other Options?
A (Qualification Rule) → Requires explicit product assignments, which is impractical for 5M+ products.
C (Advanced Rule) → Typically used for complex logic with filters (e.g., product relationships), adding overhead.
D (Context Rule) → Used for pricing context (e.g., tiered discounts), not broad product-wide logic.

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.