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.

Explanation:

The statement:
“A guided process allows you to create new product bundles in the Cart.”

…is false. Here’s why:

✅ Guided Process (Guided Selling)
Guided Selling is designed to:
Help users select existing products or bundles from the product catalog
Collect configuration data
Filter product lists dynamically
Apply rules to ensure correct product selections
Guided Selling does not create new product bundles on the fly. Instead:

✅ You create bundles in the Product Catalog (EPC) ahead of time:

Parent Product = bundle
Child Products = components
Relationships and constraints are defined during product modeling.

✅ Where product bundles are created
Bundles are modeled in:
Vlocity Product Console
Salesforce Industries Product Designer
EPC Product hierarchy

When a user opens the Cart:
They can select from pre-configured bundles.
They can customize those bundles (e.g. add/remove optional child products).
But they cannot create new bundles from scratch during the cart process.
✅ Example
Let’s say:
“Internet Bundle” → Parent Product
Child Products → Router, Security Suite
Users can:
Select this bundle via Guided Selling
Add or remove optional child products
They cannot create a new “Custom Internet Bundle” in the Cart UI.

✅ Why the statement is False
✅ Guided processes:
Help configure bundles
Help select bundles
Do not create entirely new bundles as new product entities in EPC
If you want a new bundle, a product modeler must define it in the catalog first.

Explanation:

When working with Rules in Salesforce Industries CPQ (Vlocity CPQ), you define conditions to determine when your rule should execute.

There are two ways to add conditions:
Simple
Function
Let’s explain each one.

✅ B. Simple → Correct
✅ When you choose Simple, you can:

Directly select a Context Dimension (like Account, Quote, Order, etc.)
Pick a field from that context

Define criteria like:
Equals
Not Equals
Greater Than
Less Than
Example:
Context Dimension: Account
Field: SLA
Operator: Equals
Value: Gold

This approach allows you to select the context dimension from a dropdown → that’s precisely how you map rule conditions to objects like Account, Quote, or Asset.

So Simple = pick Context Dimension + Field + Operator + Value.

✅ Why Function is Incorrect
✅ A. Function → Incorrect
Function allows you to:

Write a custom formula or expression
Reference context variables in a formula-style syntax

While powerful, Function does not offer a dropdown to pick a context dimension. Instead, you must manually write the logic.

Example:
IF(Account.SLA__c == 'Gold', true, false)

So while you can reference context dimensions inside a function, you don’t select them via a dropdown → you write it yourself.

Explanation:

Context Scopes in Salesforce CPQ/Vlocity:

Context scopes define the hierarchical level at which a rule or pricing logic is evaluated (e.g., Quote, Order, Account).
Some rules need to work independently of the root context (e.g., a discount that applies whether the root scope is an Opportunity or a Quote).

Why Option A (Any)?
The "Any" context scope is agnostic to the root context. It allows:
Rules to execute regardless of whether the root is an Account, Contract, Quote, etc.

Example: A global discount rule that applies to any context (Account, Contract, or standalone Cart).

Why Not Other Options?
B (Asset), C (Opportunity), D (Order), E (Quote): These are specific scopes tied to a single object type. They cannot operate independently of the root context.

Explanation:

When you use the Reference Application (the demo digital commerce app provided with Salesforce Industries CPQ), the process is:

User configures products in the cart.
User submits the order.
The system returns a confirmation message.

✅ What should be listed in the confirmation message?
✅ B. The Order Id → Correct

After submitting the order, the system generates:

A unique Order Id
Possibly additional metadata like status or timestamp

The Order Id is critical because:

It serves as the unique reference for:
Customer service inquiries
Tracking fulfillment
Integration with external systems (billing, provisioning, etc.)

The confirmation message always includes the Order Id so both the user and system can track the order.

Example confirmation message:
“Your order has been submitted successfully. Your Order ID is ORD-000123.”

Why the Other Options Are Incorrect:
✅ A. The Account Id → Incorrect
The Account Id might be stored internally but is not typically shown to the user in the order confirmation message.

✅ C. The cart items → Incorrect (in this context)
Cart items are displayed:

In the cart UI
During review before submission

However, they’re not required in the final confirmation message. The confirmation message focuses on:
Order Id
Status (e.g. submitted, processing)

✅ D. The total cost → Not required
While some confirmation messages may display the total cost, the key element that must appear is the Order Id.

The total cost might be shown for user convenience but is not mandatory for tracking the order.

Explanation:

Let’s look at what the question is asking:

Which of these rule types can you use to ensure that a valid combination of products is added to the Cart?

✅ The key phrase is “valid combination of products.” That means we’re talking about:

Whether products can coexist in the cart.
Whether there are conflicts or required relationships between products.
This is precisely the purpose of Compatibility Rules.

✅ B. Compatibility → Correct
Compatibility Rules (also called Advanced Configuration Validation Rules) ensure:
Certain products cannot be selected together (Excludes).
Certain products must be selected together (Requires).
Cardinality constraints are enforced (e.g. max 2 routers per bundle).

Examples:
“Cannot order Premium Data Plan with Limited Data Plan.”
“If Security Service is selected, Router must also be selected.”

This ensures that combinations of products in the cart are valid.

Why the Other Options Are Incorrect
✅ A. Availability → Incorrect
Availability Rules determine if a product is available for ordering:
Inventory constraints
Geographical serviceability
They do not validate combinations of products in the cart.

✅ C. Eligibility → Incorrect
Eligibility Rules determine:
Whether a product should appear in the catalog for a specific customer or context.
They don’t ensure that combinations of products are valid once chosen.

✅ D. All of the above → Incorrect
Only Compatibility rules directly ensure that product combinations in the cart are valid.

Explanation:

Context Rules in Salesforce Industries CPQ (formerly Vlocity) are designed to dynamically tailor the behavior of the product model based on contextual data—such as customer account attributes, opportunity stage, SLA level, etc. They are most commonly used to drive:

✅ B. Qualification
Used to determine whether a product, promotion, or offering is eligible or visible, based on account-level or other contextual information (like Account.Type = Enterprise).

✅ D. Configuration
Used to dynamically modify the structure or attributes of a product bundle during configuration, such as pre-selecting options or changing attribute values based on external data (e.g., Account.SLA = Gold ➝ Set Service Level = Full).

❌ Why the Others Are Incorrect:

A. Penalty
✖️ Penalties are tied to contractual rules, not driven by Context Rules—usually implemented via offer/contract logic.

C. Compatibility
✖️ Managed by Product Relationships (like Requires or Excludes), not by Context Rules. Compatibility is enforced via Validation or Advanced Rules, not context evaluation logic.

Explanation:

When you open the Vlocity Cart (Industries CPQ Cart), you’ll see several buttons in the top-right corner of the cart header.

These buttons are often labeled things like:

Save
Submit
Cancel
Custom actions (e.g. Validate Order, Sync Assets, Launch Approval)

These buttons are known as Vlocity Actions.

✅ What are Vlocity Actions?
✅ Vlocity Actions are:

Configurable buttons displayed in the cart UI
Defined in the Vlocity Action Setup area

Linked to:

Remote methods (Apex)
Integration Procedures
OmniScripts
Navigation to other pages

Appear in:

Cart header
Line items
Cart UI panels

Example:
The “Submit” button in the cart header → triggers the submitOrder remote method.

You do not define these buttons on Salesforce layouts, SObjects, or purely in templates.

Why the Other Options Are Incorrect

✅ B. Buttons defined on the Salesforce layout → Incorrect
Page layout buttons in Salesforce:
Are for standard Salesforce pages (e.g. Account, Order pages)
Not used in the Vlocity Cart’s custom Angular UI.

✅ C. Buttons defined in the cpq-cart-setup template → Incorrect
The template defines where buttons appear visually, but the buttons themselves (labels, actions) are managed via Vlocity Actions.
Templates handle layout, not action logic.

✅ D. Buttons defined on the Order sObject → Incorrect
Buttons on the Order object:
Exist on standard Salesforce record pages.
They don’t appear automatically in the Vlocity Cart header.

Explanation:

Product Images in Salesforce CPQ/Vlocity:
Product images can be sourced in two ways:

URLs: Links to externally hosted images (e.g., CDN, third-party storage).
Files uploaded to Documents: Images stored in Salesforce Documents or Files.

Why "True"?

Flexibility: Admins can choose between:

URLs (e.g., https://example.com/router-image.jpg) for easy external hosting.
Documents (e.g., Salesforce Files) for centralized management within the org.

Key Use Cases:

URLs: Ideal for dynamic or high-volume catalogs (e.g., Amazon S3 links).
Documents: Better for controlled/internal assets (e.g., branded product images).

Need to Configure This?
Navigate to Product Setup in Salesforce CPQ/Vlocity to define image sources.