Industries-CPQ-Developer Practice Test Questions

Explanation:

An Attribute Binding is a mechanism used within Salesforce Industries CPQ product configuration to link a generic Product Attribute, defined in the Enterprise Product Catalog (EPC), to a specific field on a Salesforce object such as a Quote Line Item, Order Line Item, or Asset. This ensures that when a user selects a value for an attribute during the configuration process, the value is correctly captured and stored in the appropriate Salesforce field.

Function
Attribute bindings are essential for persisting user selections throughout the CPQ, order capture, and fulfillment lifecycle.

Why other options are incorrect

A. It binds an attribute to a price list entry
Attributes can influence pricing through Pricing Procedures or Pricing Matrices that reference price list entries, but the binding itself connects the attribute to a Salesforce field, not directly to a price list entry.

B. It binds an attribute to a pricing variable
Attributes may be used as inputs when calculating pricing variables, but the direct binding mechanism stores the attribute value in a Salesforce field rather than binding it to a pricing variable.

D. It binds an attribute to a picklist
A Product Attribute may use a picklist as its data type for user input, but the attribute binding defines where the selected value is stored in the underlying data model, which is a Salesforce field, not merely the UI picklist itself.

References
Product Attribute Bindings (Salesforce Help)
Define Attributes and Attribute Bindings (Trailhead)

Explanation:

Promotion Pricing in Salesforce CPQ/Vlocity:
In a promotion, the total price typically includes the rolled-up prices of all child products that are part of the bundle or promotion.

Exception: Optional products that are not selected (i.e., not being purchased) are excluded from the promotion total.

Why "True"?

Child Product Roll-Up: By default, mandatory child products (or selected optional products) contribute to the promotion’s total price.
Optional Products: Only included if explicitly chosen by the user; otherwise, they are ignored in the total calculation.

Example Scenario:
A "Home Internet Bundle" promotion includes:
Mandatory: Modem ($50) + Base Plan ($30) → $80 total.
Optional: Extended Warranty ($10) → Only added to the total if selected.

Key Takeaway:

Mandatory child products always roll up to the promotion total.
Optional products only contribute if selected.

Explanation:

In Salesforce Industries CPQ (Vlocity), context dimensions are key components of context rules. They define how contextual data such as Account attributes, location, SLA, or installed technology is evaluated. For the API cache job to succeed, certain properties must be configured correctly.

Code (A)
The Code property uniquely identifies the context dimension.
If the code is missing, invalid, or duplicated, the API cache job will fail because the system cannot resolve the dimension during cache generation.

Values for caching (B)
This property defines which values should be cached for evaluation.
If values are not provided or are incorrectly configured, the cache job cannot build the lookup table required for rule evaluation, causing the job to fail.

Why the other options are not correct

C. Data Type
While the data type is important, such as string, number, or boolean, an incorrect data type usually results in rule mis-evaluation rather than a failure of the API cache job itself.

D. Default Value
A missing or incorrect default value may lead to unexpected rule behavior, but it does not prevent the API cache job from running successfully.

Conclusion
The two properties most directly responsible for API cache job failure are Code and Values for caching.

References
Salesforce Industries CPQ Developer Guide – Context Dimensions and API Cache Jobs
Salesforce Help – Configuring Context Rules and Dimensions

Explanation:

In Vlocity CME (Communications, Media, and Energy), Field Mapper is a declarative configuration tool used to move data across the sales lifecycle.

Its primary purpose is to map fields between core CRM objects such as:
Opportunity → Quote
Quote → Order
Order → downstream records such as Assets

This ensures that customer and transaction data flows consistently as a deal progresses.

Option-by-option breakdown

✅ A. A declarative tool to configure field mappings from Opportunities to Quotes to Orders
This is exactly what Field Mapper is designed for.
It requires no code and is entirely configuration-based.
It is commonly used in CME implementations to keep data aligned across objects throughout the sales lifecycle.

❌ B. A configuration tool that maps fields to product attributes
This describes Attribute Binding, not Field Mapper.

❌ C. A data loading tool used to import product catalog data
This functionality belongs to Vlocity DataRaptors and Data Packs, not Field Mapper.

❌ D. A configuration tool used to map fields to template bindings
Template bindings are used in document generation, such as OmniScript or document templates, and are not part of CME Field Mapper functionality.

📚 Key Exam Concept:
Field Mapper equals object-to-object field mapping across Opportunity, Quote, and Order.
This is a high-frequency Ind-Dev-201 exam topic, especially in CME scenarios.

Explanation:

Cardinality is configured on the Product Child Item (PCI) record within a bundle. It uses three main settings: Min, Max, and Default.

Is optional (A)
This is controlled by the Minimum Cardinality setting.
If the Min Cardinality is set to 0, the product is considered optional, meaning the customer can remove it or choose not to add it.
If the Min Cardinality is set to 1 or higher, the product is required.

Has a default quantity of 2 (D)
This is controlled by the Default Cardinality setting.
This value determines how many units of the product are automatically added to the cart when the parent bundle is selected.
If the administrator sets the Default to 2, the user will see a quantity of 2 immediately upon selection.

Analysis of Incorrect Answers

B. Is not available to customers in France
This is a logic requirement handled by Context Rules related to eligibility or availability.
Cardinality only manages how many products can be selected, not who can select them or where they are available.

C. Is discounted based on the quantity
While cardinality controls the quantity, any discount applied to that quantity is managed by the Pricing Engine using Price List Entries, Price Alterations, or Attribute-Based Pricing.
Cardinality itself does not contain discounting logic.

References
Salesforce Help: Product Cardinality in Bundles
Vlocity Documentation: Defining Min, Max, and Default Quantities for Child Products

Explanation:

Product Relationships in Salesforce CPQ/Vlocity:
Product relationships are used to define how products interact within a bundle or configuration.
The Related Product field specifies which product is affected by the relationship (e.g., auto-adding, hiding, or modifying attributes).

Why "False"?
Product relationships cannot modify attributes based on non-product-related factors (e.g., account fields, user roles).

They only modify attributes of the related product based on:
Product-specific conditions (e.g., "If Product A is selected, set Product B’s ‘Warranty’ attribute to ‘Extended’").
Other products in the bundle (not external factors).

Reference: Salesforce CPQ Product Relationships

For Non-Product Factors:
Use Advanced Rules or Context Rules to modify attributes based on external data (e.g., Account.Industry, User.Country).

Key Takeaway:
Product relationships only handle product-to-product logic. For broader conditions, use rules.

Explanation:

In the Salesforce Industries Guided Selling experience, often built with OmniScript or Product Selector components, the HTML template primarily controls the layout and visual rendering of the cart interface.

Role of HTML Templates:
HTML templates define the structure, styling, and orientation of UI components.
For the cart, this includes whether the cart items are displayed in a vertical list (stacked) or a horizontal grid (side-by-side).

Guided Selling Cart Display:
The template can switch between layouts such as:
Vertical: Items listed top-to-bottom, common for mobile or detailed views.
Horizontal: Items arranged left-to-right, common for summary views or desktops.
This is controlled via CSS classes, HTML structure, and responsive design in the template.

Why the Other Options Are Incorrect:

A. JSON for the price list Id – Incorrect.
Price list configuration is managed by pricing logic and data sources like Integration Procedures, not by the HTML template.

B. The order status – Incorrect.
Order status is a data field managed by backend processes, not controlled by the frontend HTML template.

C. Product filters to retrieve specific products – Incorrect.
Product filtering is handled by search queries, OmniScript data sources, or context rules, not by the cart’s HTML template.

E. Remote methods to be used for the cart – Incorrect.
Remote methods (APIs) are defined in JavaScript controllers or Integration Procedures, not in HTML templates.

Reference:
In Vlocity/Salesforce Industries, HTML templates are part of the Card Framework or OmniScript and control the presentation layer.
Templates can be swapped to change the UI layout without altering business logic.

Explanation:

Context Rule Assignment in Salesforce CPQ/Vlocity:
Context rules are grouped into context rule sets for organization and reuse.
When assigning a context rule to an object (e.g., Quote, Product), you assign the entire rule set, not individual rules or dimensions.

Why Option B?

Context Rule Set:
A collection of related context rules (e.g., all discount rules for "Enterprise Customers").
Assigned to objects via UI or metadata (e.g., to a Quote or Product).
Ensures consistent rule execution.

Reference: Vlocity Context Rule Sets

Why Not Other Options?
A (Context dimension): A dynamic attribute (e.g., Account.Tier), not assigned directly.
C (Context rule): Individual rules are part of a rule set; you assign the set, not single rules.
D (Context mapping): Links dimensions to data sources (e.g., Opportunity.Field), not assigned to objects.

Key Takeaway:
Assign context rule sets (not standalone rules) to enforce grouped logic.

Explanation:

This question is part of a troubleshooting scenario in Salesforce Industries CPQ (Vlocity CPQ) where product attributes are not appearing, are not updating, or are showing incorrect/outdated values in the cart, guided selling, or Digital Commerce experience — even though the attribute configuration appears correct.

The two most effective and commonly recommended actions to resolve these attribute-related issues are:

A. Run Refresh Platform Cache
Industries CPQ relies heavily on platform cache to store product, attribute, pricing, and catalog metadata for fast performance.
When changes are made to:
* Product attributes
* Attribute categories
* Attribute bindings
* Product relationships
the cache may retain old versions.
Running Refresh Platform Cache (found in Setup → Industries CPQ → Cache Management) clears and rebuilds the platform cache entries related to products and attributes.
This is the first and most common step when attributes stop showing or behave unexpectedly after configuration changes.

B. Run EPC Product Attrib JSON Batch Job
The EPC Product Attrib JSON Batch Job (also known as Product Attribute JSON Batch Job) regenerates the JSON representation of product attributes stored on the Product2 record (in the vlocity_cmt__AttributeJSON__c field) and related EPC objects.
This JSON is used at runtime by the cart, OmniScripts, and APIs to render and validate attributes quickly.
If you:
* Added, removed, or modified attributes
* Changed attribute types, picklists, or bindings
* Re-parented products or changed hierarchies
the JSON may become stale or incorrect.
Running this batch job rebuilds the attribute JSON for all (or selected) products, ensuring the cart sees the latest attribute structure.

Why not the other options?

C. Run Product Hierarchy Maintenance
This job rebuilds product hierarchy relationships (parent-child, bundle structure, catalog hierarchy).
It is useful when products are missing from the catalog, bundles are broken, or hierarchy-based filtering fails — but it does not directly affect attribute rendering or attribute JSON.

D. Run Load API Metadata
This job refreshes API metadata used mainly for Digital Commerce APIs, Integration Procedures, and external integrations.
It is relevant when API responses are missing fields or behaving incorrectly, but it does not fix attribute display or JSON issues inside the cart or guided selling UI.

Key Troubleshooting Flow for Attribute Issues
* Ensure attribute configuration is correct (product, attribute category, bindings, etc.).
* Run Refresh Platform Cache (quick and often sufficient).
* If still not resolved → Run EPC Product Attrib JSON Batch Job (especially after attribute changes).
* If hierarchy-related → then consider Product Hierarchy Maintenance.

Recommended Study
Salesforce Help: "Cache Management in Industries CPQ" — Recommends Refresh Platform Cache as the first step for most UI/metadata inconsistencies.
Salesforce Help: "EPC Product Attribute JSON Batch Job" — Describes when and why to run this job after attribute modifications.
Trailhead: "Troubleshoot Industries CPQ" and "Configure Product Attributes" modules — Cover these jobs in troubleshooting sections.

Explanation:

In Salesforce Industries CPQ, rules execute in a specific order to ensure that only the right products, prices, promotions, and attribute values appear for the user — this is critical for ensuring a Perfect Order (i.e. an order that is valid, complete, and accurate).

The proper sequence is:

1. Context Rules Framework
Evaluates whether products, prices, promotions, or attributes should be visible, enabled, or selectable, depending on contextual factors:

Customer type
Geography
Sales channel
Segment

Controls availability and eligibility of products and pricing before anything else happens.

2. Compatibility Rules Framework
Ensures that product combinations are allowed or forbidden.
Validates:

Product A cannot be selected with Product B
Product C requires Product D

This eliminates invalid configurations early in the cart session.

3. Advanced Rules Framework
Provides advanced logic and dynamic behavior:

Auto-add or remove products
Modify attributes of products
Evaluate complex logic for nested bundles

Often triggered during configuration changes or when proceeding through guided selling.

Thus, the execution sequence is:
Context → Compatibility → Advanced

Why not the others?
A. Advanced Rules Framework, Context Rules Framework, Compatibility Rules
→ Wrong order; Advanced Rules run last.

B. Eligibility Rules, Context Rules, Advanced Rules
→ Eligibility rules are technically a use of Context Rules. This option is incomplete and in the wrong sequence.

C. Context Rules Framework, Advanced Rules Framework
→ Missing the Compatibility Rules Framework.