Industries-CPQ-Developer Practice Test Questions

Explanation:

In Salesforce Industries CPQ (Vlocity), when you're configuring an entity filter to evaluate product attribute values, you must specify the Attribute Lookup Field Name. This tells the rules engine where to find the attribute values during rule evaluation—particularly when you're working with Context Rules, Advanced Rules, or Pricing Adjustments based on attributes.

Here’s why it matters:

The Attribute Lookup Field Name is used to navigate from the root or child entity to the record that contains the actual Attribute-Value pairs (often via the ProductAttribute or AssetAttribute relationship).
Without this field, the rule won’t know how to resolve the path to the attribute value, and evaluation would fail or return null.
This is essential in rules that trigger based on configurations like: “If Color = Blue AND Storage > 128GB…”

Why the Others Are Incorrect:
A. Entity Filter Type ❌ Required for overall filter configuration (e.g., RuleCondition or Qualification), but not specific to attribute lookup
B. Evaluation Criteria ❌ Refers to how filters are combined (e.g., ALL, ANY)—not how to reach attribute values
C. Formula for Conditions ❌ Used for calculated logic, but doesn’t help locate attribute fields in related records

Explanation:

Promotions are typically used for:
- B: Customer-specific pricing (e.g., VIP discounts)
- C: Targeted availability (e.g., B2C-only offers)
- E: Time-bound deals (e.g., holiday sales)

Why Not Others?
- A: Cancellation penalties are contract terms, not promotions
- D: Urgent sales are inventory/operations issues

Explanation:

In Salesforce Industries CPQ (Vlocity CPQ), Product Relationships are crucial for managing how products:

Must be sold together
Cannot be sold together
Are recommended to customers

These relationships are set up in the CPQ data model and enforced by Configuration/Validation Rules.

Let’s analyze each option.

✅ A. Requires → Correct
Indicates that if Product A is selected, Product B must also be selected.

Example:
“If you sell a security system, you must also sell an installation service.”
This relationship is mandatory.

✅ B. Excludes → Correct
Indicates that if Product A is selected, Product B cannot be selected.
Used to prevent incompatible or conflicting product combinations.

Example:
“Unlimited Data Plan excludes the Limited Data Plan.”

✅ C. Recommends → Correct
A soft relationship that suggests complementary products.
The customer can accept or ignore the recommendation.
Often displayed as:

“Customers who bought this also bought…”

Example:
“Buying a mobile phone recommends purchasing a phone case.”

Why the Other Options Are Incorrect
✅ D. Optional → Incorrect
“Optional” describes whether a child product is required in a bundle, but it’s not a formal relationship type in the rules engine.

✅ E. Limited Quantity → Incorrect
This is a business rule constraint, not a relationship type.
Managed via cardinality or rule actions, not a relationship like Requires, Excludes, or Recommends.

✅ F. Suggests → Incorrect
No official relationship type called “Suggests.” That’s simply another word for “Recommends,” but not a technical type in Vlocity CPQ.

✅ G. Not Compatible → Incorrect
“Not Compatible” is the business result of an Excludes relationship but is not itself a relationship type.

Explanation:

The postCartItems remote method in Vlocity (Salesforce Industries) CPQ is used to add items to the cart.

Primary Function: It takes a list of products or configurations and inserts them into the shopping cart (either a new or existing cart).

Common Use Case: When a user selects products from a catalog or an OmniScript, this method is called to add them to the cart before checkout.


Not Used For:
Submitting an order (B) → Typically handled by submitOrder or placeOrder methods.
Filtering products (A) → Done via queries or getCarts/getProducts methods.
Moving orders to next stage (E) → Managed by order workflows or OmniScript navigation.
Selectables list (C) → Usually populated via getProduct or getSelectableItems methods.

Explanation:

Telecommunications companies often operate with highly complex product catalogs, legacy systems, and intricate service fulfillment processes. As a result:

New hires—especially in sales, service, or operations—require deep understanding of configurations, systems, and customer flows
Onboarding programs can be lengthy and resource-intensive, especially without guided digital tools
Industries like telecom have historically struggled with knowledge silos and manual processes, increasing ramp-up times

This is one of the reasons why platforms like Salesforce Communications Cloud emphasize Guided Selling, process automation, and streamlined training assets to accelerate onboarding and reduce time to productivity.

Explanation:

In Salesforce Industries CPQ (Vlocity CPQ), Context Rules are used to determine:

Whether certain products should appear in the catalog
Eligibility of products
Dynamic pricing
Other rule-based logic tied to context (e.g. Account, Quote, Opportunity)

To achieve this, Context Mappings link data in the org (like fields on sObjects) to the context used by the Rules Engine.

✅ What goes in the source expression?
✅ A. The API name of an sObject field → Correct

In a Context Mapping:
The Source Expression is the API name of the field you want to evaluate.

This tells the Rules Engine:
“When evaluating this rule, fetch this value from this field.”

For example:

If you want to evaluate the Account’s Segment:

Source Expression = Segment__c

Or if using a standard field:

Source Expression = Industry
This is how the Context Rule Engine retrieves values for rule evaluation.

Why the Other Options Are Incorrect
✅ B. %%field%% → Incorrect
That’s syntax for document templates, not for context mappings.

✅ C. {{field}} → Incorrect
This is Handlebars/Mustache syntax used in templates—not context mappings.

✅ D. A calculated formula used by the context rule service engine → Incorrect
You cannot directly enter complex formulas in the Source Expression field.
The field expects an API field name.
Any calculations must be performed either:
Before rule execution

In the rule’s filter logic, not in the source expression itself.

Explanation:

In Salesforce Industries (Vlocity) CPQ, Promotions are used for time-bound or targeted discounts/incentives, while Offers are more permanent product bundles or recommendations.

When to Use a Promotion Instead of an Offer?
A. Limited Customer Set → Promotions can target specific segments (e.g., VIPs, geographic regions).

C. Limited Time Availability → Promotions are ideal for seasonal/urgent deals (e.g., Black Friday discounts).

D. Quick Sales Boost → Promotions drive urgency (e.g., "Limited stock at 20% off").

Why Not the Others?
B. B2C Customers Only → Offers and promotions can both target B2C/B2B; this doesn’t dictate the choice.

E. Product Cost Increasing → Pricing adjustments (e.g., price rules) handle this, not promotions.

Explanation:

The Vlocity Cards Framework (now part of OmniStudio under Salesforce Industries) is the foundation for creating FlexCards, which are dynamic UI components used to present data in context across desktop, mobile, and portal experiences.

Here's what it provides:

✔️ Cards These are the actual FlexCards, which display summarized or detailed information—like customer profile snippets, account balances, or order details.

✔️ Layouts Layouts define how multiple cards are displayed on the page (e.g., vertical stack, horizontal tabs, or custom arrangements). You can create responsive UIs without heavy custom code.

✔️ Templates Templates offer reusable HTML/CSS structures for cards—controlling look and feel such as styling, spacing, and behavior like modals or drill-downs.

Together, these empower non-developers to quickly build modular, context-aware interfaces with minimal coding.

❌ Why the Others Are Incorrect:
B. Cards and pre-built wizards ❌ “Wizards” (step-by-step UI flows) are part of OmniScripts, not the Cards Framework

C. Templates for ad-hoc promotions ❌ Promotion setup is handled via Product Console or Promotions framework, not through Cards

Explanation:

When you assign a time plan to a child product in a promotion:

It controls the duration of the promotional price for that specific child product.
The time plan does not affect the parent product or overall promotion expiration.

Example: A 3-month discount on a phone accessory (child) while the main device (parent) has no time limit.

Why Not the Other Options?

B. Incorrect → The promotion’s end date is set separately (not by child product time plans).
C. Incorrect → Customer eligibility is determined by qualification rules, not time plans.
D. Incorrect → Start times are configured in the promotion setup, not the time plan.

Explanation:

In Salesforce Industries CPQ, Guided Selling provides an intuitive, interactive interface that assists users (especially sales reps) in selecting the right products for customers by walking them through a series of steps and pre-configured logic.

Here's how each of the correct features fits into the Guided Selling experience:

✅ A. Summary of assets
The system can fetch and display previously purchased products or services using the GetAsset API or pre-integrated DataRaptors, helping reps identify upsell or cross-sell opportunities.

✅ B. Step-by-step process
At its core, Guided Selling is a multi-step UI built with OmniScripts, designed to collect preferences, show filtered product choices, and guide users through product selection.

✅ D. Automatic totaling
As users add products to the cart, totals are updated in real-time using pricing engines and remote methods like getBasketDetails, ensuring visibility of the running total.

✅ E. Ability to edit items
Through persistent cart behavior and configured buttons/components, users can modify quantity, attributes, or remove items right from the Guided Selling UI.

❌ Why the Other Options Don’t Apply:
C. Launch cart from account/order
Not a feature of Guided Selling itself. Cart launch happens via actions configured on Account, Opportunity, or Quote but isn't visible within Guided Selling UI.

F. Change the price book
Price book (or Price List) is set at cart creation, not something users typically modify during the Guided Selling flow. It’s usually handled by backend logic.