Free Industries CPQ Developer Practice Test Questions (2026)

Explanation:

In Salesforce Industries CPQ with Asset-Based Ordering (ABO) enabled (very common in Communications, Utilities, etc.), when a user performs a Change action on an existing asset (via Change to Order from the Service Asset Management view or asset list), the system creates a Change Order that modifies the existing asset/service.

Key behavior in Change orders:
- Recurring charges → Carried over from the existing asset (usually at the original or current contracted rate).
- One-time charges (e.g., installation fee, activation fee, equipment purchase fee, early termination fee) → Automatically zeroed out or excluded on the Change order line items.

This is intentional design:
- One-time charges were already billed/paid when the original order was fulfilled and the asset was created.
- Re-applying the same one-time charge on a Change order would result in double-billing the customer.
Therefore, Industries CPQ zeros out or suppresses one-time charges on MACD Change orders (including Change, Add, Move) by default.

When the developer reviews the Change order in the Cart:
- The price shown reflects only the recurring charges (or any new/modified charges specific to the Change).
- Any original one-time charges from the asset history are not included → total price appears lower than what was shown in the Service Asset Management view (which typically displays the full historical or lifetime value of the asset, including original one-time fees).

Why not the other options?
A. The asset was originally priced for a different user. Incorrect. Pricing is tied to the product/price list/contract — not the individual user who ordered it originally.

B. Asset has a status of Disconnect in Change orders. Incorrect. A Change order does not set the asset status to Disconnect (that's a Disconnect order type). Change orders keep the asset active and modify attributes/services.

D. The product's price has changed. While possible in theory, this is not the most common or expected reason in this specific scenario. The question describes a discrepancy between asset view and Change order cart — the standard, built-in behavior is one-time charges being zeroed.

Key Concept Summary
- Service Asset Management view → Shows historical/lifetime value of the asset (including original one-time charges).
- Change to Order (Change order in Cart) → Only includes ongoing/recurring charges + any new delta charges → one-time charges are zeroed by default.
This prevents double-billing and is standard ABO behavior in Industries CPQ.

References:
- Trailhead: "Asset-Based Ordering" and "MACD Order Types" modules — Describe how one-time charges are handled (suppressed/zeroed) in Change orders.
- Salesforce Help: "Change Orders in Asset-Based Ordering" — Notes that one-time charges from the original fulfillment are not re-applied in Change/MACD flows.

Explanation:

✅ Correct Option: {{field}}
This is the standard syntax used in Vlocity Document Templates. The double curly braces {{ and }} are a widely recognized convention in many templating engines to denote a placeholder that will be replaced with a dynamic value, or merge code, at the time of document generation. In this context, field represents the name of the data field from a Salesforce object (e.g., an Opportunity or Quote) that you want to display in the document. This syntax ensures that the template engine correctly identifies and substitutes the data.

❌ Incorrect Option: %field%
This is not the correct syntax for merge codes in Vlocity Document Templates. The single percentage signs %field% are a different type of placeholder syntax sometimes used in other systems or older platforms, but they are not the standard for Industries CPQ Document Generation. Using this syntax will result in the text being rendered as-is in the final document, without any data being merged.

❌ Incorrect Option: %%field%%
This syntax is also not correct. While the double percentage signs %%field%% are a known convention for merge fields in some other applications, they are not used for Vlocity Document Templates. Attempting to use this syntax will cause the merge code to fail, and the literal %%field%% string will appear in the generated document.

❌ Incorrect Option: {%field%}
This syntax, which combines curly braces and percentage signs, is not a valid format for Vlocity Document Templates. This specific pattern is often used in different programming or templating languages for control flow statements (like loops or conditional logic) rather than for simple variable substitution. Using it for a merge field will not work and will likely result in an error or display the text exactly as it is written.

Summary:
The question asks about the syntax for merge codes in Vlocity Document Templates. These templates allow for the dynamic generation of documents like quotes, contracts, and proposals by pulling data from Salesforce records. The syntax is a critical component for ensuring that the correct data is populated in the right places within the document.

Reference
Salesforce Industries CPQ and Document Generation
Vlocity Document Templates Syntax

Explanation:

In Asset-Based Ordering (ABO) within Salesforce Industries CPQ, when a customer already has an active plan (like the Family Simple Choice Plan) and decides to add a new product (Smart Cloud Security), the system creates an order from the existing asset.

The Family Simple Choice Plan is not being modified in this scenario — it remains as-is.

Therefore, its line item action status in the order is marked as Existing, indicating that the asset is carried forward unchanged.

The Smart Cloud Security product would have the action status Add, since it is a new product being added to the customer’s assets.

Option Analysis:
A. Existing (Correct): The Family Simple Choice Plan remains unchanged, so its status is "Existing."
B. Change: Would apply if the plan itself was being modified (e.g., upgrade/downgrade).
C. Add: Applies to the new Smart Cloud Security product, not the existing plan.
D. Configured: Refers to products being configured in the cart, not the asset status in the order.

Key Concept
Existing = Current asset carried forward unchanged
Add = New product added to the asset base
Change = Modification of an existing asset
Disconnect = Removal of an existing asset

References
Salesforce Industries CPQ Developer Guide: Asset-Based Ordering (ABO) and Line Item Actions
Salesforce Help: Order Management and Asset Lifecycle

Explanation:

In Salesforce Industries CPQ (Vlocity), when adjusting the price of a child product, you're not directly modifying the base price. Instead, the system leverages Pricing Elements to layer adjustments on top of the base price. These elements preserve the original price and apply deltas through well-defined calculation logic.

Here’s how it works:
When a price is adjusted—for example, when a user applies a manual discount or configuration-driven adjustment—a new Pricing Element (like a one-time charge, recurring charge, or adjustment) is created.
These pricing elements are stored and referenced during cart recalculations via Price Calculation Matrix rules or Adjustment Classes.
So rather than overwrite the base, the CPQ engine adds an additional pricing layer, which offers flexibility for promotions, rules, and pricing transparency.

Why the Other Options Are Incorrect:
A. "The base price is overridden…" ❌ – The base price remains untouched; the CPQ engine preserves it as the anchor for pricing logic.
B. "The change… can be a percentage or amount" ❌ – While true in terms of adjustment types, this isn’t the mechanism for price updates. The update happens via pricing elements, not direct modification.

Explanation:

🔎 Importance of the Code Property
The Code property is the unique identifier for a rule property in Industries CPQ. It is critical because the CPQ engine references this Code during evaluation, caching, and execution. If the Code is missing, duplicated, or incorrectly formatted, the API cache job cannot resolve the property correctly. This leads to ambiguity in rule execution and causes the cache job to fail. For example, if two properties share the same Code, the system cannot distinguish between them, preventing the cache job from building a reliable execution model. Ensuring that each property has a valid and unique Code is therefore essential for successful cache job execution.

🔎 Importance of the Data Type Property
The Data Type defines the kind of values a property can hold, such as String, Number, Boolean, or Date. During the cache job, the system validates that the property’s values align with its declared Data Type. If the Data Type is invalid or mismatched—for instance, if a numeric value is stored in a String property—the cache job fails because rule evaluation depends on correct typing. Without proper Data Types, comparisons, calculations, and logical evaluations cannot be executed reliably. This makes Data Type validation a critical step in ensuring that rules can be cached and executed consistently.

🚫 Why Not Default Value or Values for Caching
Default Value (B): While useful for runtime behavior, a missing or incorrect default does not cause the cache job to fail.
Values for Caching (D): These are used for optimization and performance tuning but are not mandatory for cache job success.

📖 Reference
Salesforce Industries CPQ Developer Guide – Context Rules and API Cache Jobs
Trailhead: Optimize Industries Cloud Cache Management

Explanation:

An Advanced Rule is composed of several parts: the Rule header, the Rule Actions, and the Rule Filters.

Flexibility: A rule is not strictly required to have a filter to function. If a rule has 0 filters, the rule is considered "unconditional," meaning the Rule Action will always execute when the rule is triggered.
Logical Evaluation: When you have 1 or more filters, the Rule Sets evaluate the criteria (Entity Filters) to determine if the Rule Action should be applied.
Entity Filters: You can associate multiple Entity Filters with a single rule. These filters act as the "If" part of an "If-Then" statement. For example, a filter might check if the account is in a certain state or if a specific product is already in the cart.

Analysis of Incorrect Answers

A. 1
❌ This is too restrictive. Advanced Rules are designed to handle complex business logic that often requires multiple criteria (filters) to be met before an action (like adding a product or displaying an error) is taken.
B. 1 or more
❌ This is incorrect because it implies that a filter is mandatory. In practice, you can create a rule that always fires without needing a specific entity filter to validate conditions first.
D. 0-3
❌ There is no hard-coded limit of three filters in the Industries CPQ architecture. The system allows for a flexible number of filters to be evaluated to meet complex enterprise requirements.

References
Salesforce Help: Rules Components — This documentation outlines how Entity Filters (Conditions) and Rule Actions (Results) work together.
Vlocity University/Trailhead: Build Advanced Rules in Industries CPQ.

Explanation:

The requirements are:
Automatically included when the bundle is added → Default Cardinality = 1.
Option to remove it → Minimum Cardinality = 0 (user can reduce quantity to zero).
Cannot add more than one TV service per bundle → Maximum Cardinality = 1.

D is Correct: This configuration (Min=0, Default=1, Max=1) perfectly meets all requirements. The TV service starts in the cart (Default=1) but can be removed (Min=0), and you cannot add a second one (Max=1).

Why the other options are incorrect

A. Min=0; Default=1; Max=0: Maximum Cardinality = 0 is impossible and contradictory. If the maximum is 0, the product cannot be included at all, making the default of 1 invalid. This configuration would cause an error.

B. Min=1; Default=1; Max=1: Minimum Cardinality = 1 means the product is mandatory and cannot be removed. This violates the requirement that the customer should have the option to remove it.

C. Min=1; Default=0; Max=0: This configuration is also contradictory and invalid. Min=1 requires at least one, but Max=0 prohibits any. Furthermore, Default=0 fails the "automatically included" requirement.

Key Concepts
Minimum Cardinality: The fewest number of this item that must be in the bundle. 0 = optional, 1 = required.
Default Cardinality: The initial quantity added when the bundle is first placed in the cart.
Maximum Cardinality: The most of this item allowed in the bundle.

Reference
Salesforce Industries CPQ Documentation: "Create a Product Bundle" or "Configure Bundle Members." The documentation explains that cardinality settings control the optionality, default quantity, and limits for child products within a bundle. This scenario is a classic use case for Min=0, Default=1.

Explanation:

The requirement is to set prices based on configurable service attributes such as Bandwidth (1 GB versus 10 GB) and Network type (Internet versus External). This scenario directly matches the definition of Attribute-Based Pricing, where pricing is determined by the selected product attributes.

D. Correct (Attribute-Based Pricing)
To meet this requirement, the developer would configure an Attribute Pricing Matrix, or a Range Attribute Matrix for the numeric Bandwidth attribute. Each row in the matrix defines pricing outputs for a specific combination of attribute values, for example:

Row 1: Bandwidth = 1 GB, Network = Internet → Monthly Price = $10, One-Time Price = $5
Row 2: Bandwidth = 10 GB, Network = External → Monthly Price = $20, One-Time Price = $0

This approach ensures the correct price is automatically applied based on the customer’s configuration choices.

Why the other options are incorrect

A. Usage Pricing
Usage Pricing is intended for consumption-based charging, such as a cost per unit of usage over time (for example, $0.10 per GB consumed). In this case, pricing is fixed based on selected service tiers rather than variable usage, so Usage Pricing is not appropriate.

B. Context rules for pricing adjustments
Context Rules are used to enforce product relationships such as Requires, Recommends, or Excludes. They do not define base pricing based on attribute selections. Pricing adjustments typically apply discounts or surcharges on top of an already determined base price.

C. Cost and Margin Pricing
Cost and Margin Pricing focuses on internal cost structures and profitability calculations. It is not a customer-facing pricing mechanism driven by configurable product attributes, making it unsuitable for this scenario.

Key Indicator
When the price of a product depends directly on configuration choices or attribute values, Attribute-Based Pricing is the standard and correct solution.

Reference
Salesforce Industries CPQ documentation on Attribute-Based Pricing describes this method as setting prices based on product characteristics or attributes, which aligns exactly with the scenario described.

Explanation:

When working in the Vlocity Cart (the Industries CPQ cart interface), several rule types exist to control how products are:

Required
Excluded
Validated for compatibility

The specific rule type that runs in the cart line items panel to determine required/excluded products and compatibility is:

✅ A. Configuration Validation (Compatibility) Advanced Rules
These rules check relationships and compatibility between products in the cart.
They determine:

If certain products are incompatible (must not be ordered together)
If certain products are required when another product is chosen
Whether combinations violate business rules

Often used for:

Telecom bundles (e.g. you can’t sell a certain device without a compatible data plan)
B2B configurations
Complex product relationships

These rules execute during cart operations, such as:

Adding/removing products
Changing quantities
Modifying configurations

If an incompatibility is detected:

The cart shows error or warning messages
The user is prevented from proceeding until conflicts are resolved

Why Other Options Are Incorrect
✅ B. Evaluation Context Rules → Incorrect
Evaluation Context Rules execute in the context of pricing and eligibility but are not the primary mechanism for determining compatibility or required/excluded products in the cart UI.

✅ C. Qualification Context Rules → Incorrect
These determine eligibility for offers/products based on customer context (e.g. Account type, location) but don’t handle compatibility or required/excluded logic inside the cart.

✅ D. Configuration Validation (Compatibility) Context Rules → Incorrect

There’s no rule type specifically called “Configuration Validation (Compatibility) Context Rules.” That’s a mixing of terms from two different rule types.

Explanation:

In Salesforce Industries CPQ, when you want to create a bundle where specific child products are discounted (e.g., 20% off a child accessory or service when the bundle is added), you configure the discount directly in the promotion that targets the bundle.

The exact place to set discounts on individual child products is in the Product Structure section of the promotion (also called the Promotion Products or Child Product Adjustments area).

Steps:
- Create or edit a Promotion record.
- In the Promotion Designer, go to Product Structure (or Promotion Applies To → select the bundle parent product).
- Expand the child products under the bundle.
- For each child product you want to discount, add a Pricing Adjustment (percentage or amount off) or Pricing Override (fixed price) directly on that child line.
- Save → when the bundle is added to the cart and the promotion applies, the child products will show the discounted prices.

This is the declarative, reusable way to discount child products within a bundle via a promotion.

Why the other options are incorrect:
A. The price list where the price list entry is located:
Price Lists define the base price (list price) of products — not promotional discounts. You do not discount child products in a promotion by editing the price list.
C. The cart currently open:
In the cart you can manually apply discounts (e.g., manual adjustment on a line item), but this is not how you configure a reusable bundle promotion that automatically discounts child products when the bundle is added. Cart-level changes are one-off, not part of the bundle/promotion definition.
D. The cart currently open:
Same as C (likely a duplicate option in the test).

Reference
Trailhead: "Build a Promotion" and "Adjust the Pricing of Child Products" units — Explicitly show going into the product structure of the bundle inside the promotion to add adjustments/overrides on child products.
Salesforce Help: "Promotion Product Structure" — "In the product structure section of a promotion, you can define pricing adjustments and overrides for child products in the bundle."