Explanation:

In Vlocity CME (now Salesforce Industries CPQ), product attributes are stored as structured JSON data so the Cart, UI, and APIs can quickly render attribute values for products.

When you:
Add or edit product attributes
Change attribute default values
Add new picklist values for attributes
…the JSON blobs must be regenerated so the UI displays the latest attribute data.

The job that handles this is:

✅ EPCProductAttribJSONBatchJob
It regenerates JSON payloads for all products in your catalog.
It ensures the attribute data stored in JSON fields matches the latest attribute model.

Without running this job:

New attributes won’t appear in the Cart UI.
Old attribute values may still display.
This job is critical any time you make changes to attribute definitions.

Why not the other options?

B. ProductAttributesBatchProcessor
Not the job used for regenerating attribute JSON. The name sounds similar but is incorrect in this context.

C. ProductHierarchyBatchProcessor
Related to building the product hierarchy tree, not attribute JSON regeneration.

D. ResolveProductHierarchyBatchJob
Rebuilds hierarchy relationships and path info—not attribute JSON blobs.

Explanation:

In Salesforce Industries CPQ (formerly Vlocity), the pricing architecture has multiple layers:

Price List → a collection of prices for products.
Price List Entry → a single record linking a product to a price in a price list.
Pricing Element → defines the type of price or charge (e.g. Base Price, Discount, Tax, Surcharge, etc.).
Pricing Variable → a value that can be used in price calculations (e.g. Quantity, Region).

When you want to indicate what kind of price is being assigned to a product (e.g. base price vs. discount vs. surcharge), you define a Pricing Element.

Examples of Pricing Elements:

Base Price
One-Time Charge
Recurring Charge
Discount
Tax

Thus, the pricing element:
Describes the nature of the price being applied.
Tells CPQ how to categorize and handle that amount during calculations.

Hence, to answer:

Which of these do you create to indicate the type of price that will be assigned to the product?

✅ The answer is Pricing element.

Why not the other options?
A. Price list
It stores a collection of prices but does not define the type of price.

C. Pricing variable
Used in formulas or calculations, e.g. Quantity or custom variables—not for defining price types.

D. Price list entry
Connects a product to a price value in a price list but does not define the price type—that’s done by the pricing element assigned to the price list entry.

Explanation:

In Salesforce Industries CPQ, Configuration Rules and Validation Rules are part of the Advanced Rules Framework that help define relationships between products to ensure accurate and compliant configurations.

These rules can:

Require one product when another is selected
Exclude incompatible products from being selected together
Recommend companion products
Validate that product combinations meet business logic

For example:
If Product A requires Product B, a configuration rule enforces that relationship.

A validation rule might prevent saving a quote if Product A is selected without Product B, ensuring the relationship is respected.

These relationships are modeled using Product Relationship objects and executed through Compatibility Rules or Validation Rules during cart configuration.

Explanation:

Prices displayed in the selectable product list (the left-hand pane showing product search results) are:

Taken directly from the Price List Entry record.
List Price is shown without calculations from:
Advanced Rules
Context Rules
Promotions

This list price helps users know the base price before adding items to the cart.

Why not the other options?

B. Using Advanced Rules pricing rules
Advanced Rules only run after the product is in the cart.
They adjust prices, discounts, or attributes once you configure the product.

C. Using Context Rules associated with the price list
Context Rules determine whether a product is shown or hidden but don’t change the displayed price directly in the selectable list.
They can restrict which products appear, but the price still comes from the list price.

D. All of the above
Incorrect. Only list price shows in the initial selectable list. Other rules run later during cart configuration.

✅ Process Flow
Product Search → displays list price from Price List Entry.

Add to Cart → triggers:
Advanced Rules
Context Rules
Promotions
Only then is the final price recalculated.

So from your photo:
“LIST PRICE: $999.99” for the iPhone X is the list price stored on the Price List Entry. That’s not yet adjusted by rules.

Explanation:

In Salesforce Industries CPQ (Vlocity Cart), promotions are typically applied to an order by manually selecting them from the promotions list and clicking Add to Cart. This action triggers the system to:

Attach the promotion to the relevant product or bundle
Apply any associated discounts, attribute overrides, or cardinality changes
Update the cart pricing and structure accordingly

This manual step ensures that users have control over which promotions are applied, especially when multiple promotions are available for a given bundle.

❌ Why the other options are incorrect:

B. Automatically using context rules Context rules filter and qualify promotions but do not automatically apply them. They determine eligibility, not execution.
C. Promotion Hierarchy Batch job This job is used for maintaining promotion structures, not for applying promotions during cart operations.
D. Take me there configuration icon This is a navigation aid, not a mechanism for applying promotions.

Explanation:

Let’s break down the requirements implied in the question:

There are multiple phones (e.g. iPhone X, iPhone 8, etc.).
Each phone has a Color attribute.
Different phones might have different sets of allowed colors (e.g. iPhone X → Black, Silver, iPhone 8 → Gold, Silver).

The solution should follow best practices in Vlocity (Salesforce Industries) product modeling.

Why B is Correct
✅ B. Create a Color attribute and assign it to an object type. Create products for each phone using the object type, and override the inherited Color attribute's picklist with a custom picklist.

You create one reusable attribute Color.
Assign it to the object type (e.g. Phone Object Type).

When defining each phone as a product:

You override the inherited picklist values to match that specific product’s colors.
This avoids duplicating attributes or object types for every phone model.
Overrides are the correct best practice when the attribute exists for all products but has different allowed values for each product.

This is the recommended approach per Salesforce Industries product modeling guidelines.

Why not the others?

A. Create an object type for each phone. Create a Color attribute, and assign it to each of the object types. On each object type, override the default picklist with custom picklist.
❌ Incorrect.
Creates too many object types.
Poor maintainability—object types are designed for major product families, not individual SKUs.

C. Create Product2 record types for each phone. Create a Color attribute and assign it to the record types. Create global picklist for each set of possible colors, and assign the picklist to the record types.
❌ Incorrect.
Record types are part of Salesforce standard objects, not the Vlocity EPC data model.
Vlocity uses object types and attributes instead.

D. Create a Color formula field on the Product2 object. Use a function to display different values depending on a product code lookup.
❌ Incorrect.
This hardcodes logic into a formula, violating CPQ’s flexible, declarative model.
Not maintainable or scalable.

Explanation:

Product Attributes in Vlocity/Salesforce CPQ:

An attribute becomes a product attribute when it is assigned to a product or an object type (e.g., "Smartphone") that is used by products.

This links the attribute to the product’s configuration.

Why Option B?

Direct Association:
Attributes are inert until assigned to a product/object type.

Example: A "Color" attribute only affects products after assignment.

Reference: Vlocity Attribute Management

Why Not Other Options?

A (Product2 object): All attributes technically apply to Product2, but assignment activates them.
C (Vlocity Product Console): Just a UI tool; doesn’t define attribute types.
D (Type): No "Product Attribute" type exists—attributes gain context via assignment.

Explanation:

When you adjust the price of a product for a promotion in Salesforce Industries CPQ (formerly Vlocity):

You’re modifying pricing data, not the product hierarchy or core catalog structure.

Promotions and price adjustments:
Are stored as records linked to products or price list entries.
Do not change the parent-child relationships of products in the hierarchy.
Do not require platform cache refresh in most cases for price updates.

Hence:

You do NOT have to run Product Hierarchy Maintenance when merely updating prices or promotions.
You also typically do NOT need to refresh platform cache simply because of price changes—price data is fetched fresh during cart calculations.

Running jobs like:

Product Hierarchy Maintenance
Refresh Platform Cache
→ These are necessary when you:

✅ Change the structure of the product hierarchy (e.g. new parent/child relationships).
✅ Add new products to the catalog that should appear in search trees.
✅ Change data that affects cached catalog structures (like hierarchy paths).

But price adjustments for promotions don’t require these jobs.

Example
You change the promo discount for “iPhone X” from $50 off to $75 off.
This update happens directly in the promotion or price adjustment record.
No need to run maintenance jobs afterward.

Explanation:

In Salesforce Industries CPQ, when you perform a deep delete on a promotion, it removes:

The promotion itself
All discounts, cardinality changes, and products directly associated with that promotion

This ensures that the cart is fully cleaned of any promotional influence tied to that specific offer. It’s the default behavior controlled by the DeleteServices setting in Vlocity CMT Administration2.

❌ Why the other options are incorrect:
A. Removes everything from the Cart, including unrelated products Deep delete only affects the promotion and its related items, not unrelated products.
C. Removes the promotion, but nothing else That describes a shallow delete, which only removes the promotion and its discounts, leaving the products in the cart.

Explanation:

In Salesforce Industries CPQ (formerly Vlocity), the standard way to generate custom PDF quotes is through:

✅ Vlocity Document Templates

These are:

Templates designed in Microsoft Word or other document editors, then uploaded into the Salesforce org.
Connected to CPQ objects (e.g. Quote, Order, Account).
Capable of dynamically merging data:

Customer names
Quote line items
Pricing details
Custom fields

The process:

Design the template in Word (or any DOCX editor).
Upload it to Salesforce as a Document Template.
Configure bindings so template fields pull data from CPQ objects.
Users can then generate PDF quotes directly from the Cart or Quote UI.
This allows for highly customizable quote documents without coding or custom integrations.

Hence, the correct answer is:

✅ D. Vlocity Document Templates

Why not the others?

A. Integration with Microsoft Word
❌ Partially true—templates originate from Word—but the CPQ system uses Vlocity Document Templates to generate PDFs, not a direct runtime integration with Word.

B. Copy and pasting screen text
❌ Not a scalable or professional approach for PDF quotes.

C. Custom integration for each customer deployment
❌ Unnecessary. The product’s built-in Document Templates feature eliminates the need for custom integrations in most cases.

Explanation:

In Salesforce Industries CPQ, to configure a flat price bundle, you typically:

Set the parent product’s price to the total bundle price (Option D). This ensures the bundle appears as a single-priced item in the cart.
Zero out the child product prices (Option A). This prevents child products from contributing additional cost and keeps the bundle price fixed.

This approach is commonly used when:

You want to simplify quoting with a single price for a bundle.
You’re offering promotional pricing that hides individual component costs.
You’re using bundled product options or option pricing overrides to suppress child pricing.

❌ Why the other options are incorrect:

B. Change the child products that are not optional to zero
This is too narrow. You should zero out all child products, not just non-optional ones.

C. Change the price of the parent product to zero
That would make the bundle free unless child products contribute pricing—which defeats the flat price goal.

E. Do nothing, you can't create a bundle with a flat price
Not true! Flat pricing is a well-supported strategy in CPQ using bundled options and overrides.

Explanation:

The Take-Me-There feature in the Industries CPQ Cart (formerly Vlocity):

Appears as a clickable icon or link next to error or warning messages in the cart.

When you click it:
It navigates directly to the Line Item Details modal for the affected product.
Highlights fields or attributes that still require configuration (e.g. missing required attributes, invalid combinations).
Helps users quickly locate and resolve issues that prevent the order from being complete or valid.

Hence, it:

✅ Shows you where more details are needed to complete the order.

Why not the other options?

A. Directs you to the customer account page
❌ Incorrect. It works at the cart item level, not the customer record level.

B. Takes you to the product configuration in the master product catalog
❌ Incorrect. It opens the Line Item Details modal for the item already in the cart, not the catalog.

C. Provides optional guidance on item configuration
❌ Partially true—but the core purpose is to take you directly to fix incomplete data, not merely offer optional guidance.