Free Practice Questions for Salesforce AP-223 Exam

This use case describes a three-dimensional pricing model where the price of a product is determined by length × width × height. These values are user selections (likely stored on Quote Line fields), and CPQ must determine the correct price based on a matrix of dimensions.

Salesforce CPQ documentation identifies Lookup Tables used with Price Rules as the standard method for implementing matrix or multi-attribute pricing.

✔ Why Price Rule with Lookup Table is the correct answerSalesforce CPQ Lookup Tables allow you to store pricing data externally from the product record and return the correct price based on multiple inputs.

Lookup tables can key off of multiple dimensions, e.g.:

Length

Width

Height

A price rule performs the lookup at calculation time and sets:

List Price, or

Custom price field

Create custom fields on Quote Line:

Length__c

Width__c

Height__c

Build a Lookup Table with key columns:

Length range

Width range

Height range

Resulting price

Build a Price Rule that uses:

Price Conditions → to map entered dimensions

Lookup Query → to fetch matching price

Price Action → to set the Quote Line's Unit Price

Relevant capabilities:Typical CPQ design for dimensional pricing:This is exactly the pattern Salesforce recommends for multi-attribute pricing.

❌ Why the other options are incorrectA. Percent of TotalUsed for:

Support fees

Add-on fees based on parent productsNot for dimensional pricing.

B. Multi-Dimensional Quoting (MDQ)Used for:

Term-based pricing (Year 1, Year 2, Year 3)

Usage tiers over time

MDQ does not support 3-dimensional physical attributes.

C. Discount ScheduleSupports:

Volume tiering

Quantity-based pricing

Does not support multi-attribute dimensional pricing.

For multi-level discount approvals in CPQ:

A – Identify backup approvers: Required because Salesforce Approval Processes must account for out-of-office or unavailable approvers.

D – Define discount thresholds for sales reps: Mandatory so the system knows when to trigger approvals.

E – Document approval levels: Ensures clear governance and reduces ambiguity.

Incorrect options:

B printing approval matrices is not a Salesforce implementation requirement.

C contradicts the purpose of approval controls.

Thus the correct answers are A, D, E.

In a Salesforce CPQ scoping session, the first documentation created is the Business Process Map, because:

It defines the customer’s selling, quoting, approval, pricing, contracting, renewal, and ordering processes.

It ensures all stakeholders are aligned on “how the business works now” before CPQ design begins.

Only after processes are mapped can product structure, order management, and quote document needs be designed.

Salesforce Revenue Cloud methodology always starts with:

Business Process Documentation → Requirements → Solution Design

Thus C is correct.

When users log in to Salesforce CPQ for the first time, the Post-Install Script must run.

This script:

Initializes CPQ user settings

Creates required calculation metadata

Ensures Quote + Quote Line permissions and defaults work

Enables Primary Quote logic

If an automation tries to set a new Quote as Primary, but the user has not run the CPQ post-install script, CPQ raises errors because internal references and fields are not yet initialized for that user.

This is a documented CPQ requirement.

Thus, A is correct, and all other options point to permission issues that do NOT cause this specific failure pattern.

In Salesforce CPQ + Billing (Revenue Cloud), heavy use of cross-object formula fields can create serious performance, calculation, and reliability issues. Salesforce product documentation and CPQ study guides highlight several risks related to:

Quote calculation engine performance

SOQL query depth

Runtime evaluation limits

Data availability timing during synchronous calculations

Below is the breakdown of the options:

✅ A. Formula field data is not always available during CPQ quote calculationCorrect.

Salesforce CPQ reads values at calculation time, but cross-object formula fields may:

Not resolve in time if they depend on parent records updated within the same transaction

Return stale values because formula evaluation is not recalculated in real time mid-calculation

Fail during QCP or price rule evaluation due to record access/state issues

This is a known risk documented in CPQ technical architecture guidance.

❌ B. Formula fields have unlimited access to object many relationships away which makes it vulnerable to data changes.Incorrect.

Formula fields do NOT have unlimited access. They are limited to 10 relationship levels.

While data changes on parent objects can affect formula results, this is not a primary risk emphasized in Revenue Cloud implementation guidance.

Therefore, not one of the three correct risks.

✅ C. They are computationally expensive.Correct.

Formula fields—especially cross-object ones—are recalculated at runtime every time:

The referenced record is queried

CPQ calculator reads them during price rule evaluation

Billing processes (Invoice Run, Usage Rating, etc.) reference them

This can significantly slow down:

Quote calculations

Order/Invoice generation

Any multi-object SOQL-heavy logic

This is a well-known performance risk.

✅ D. They can easily exceed limits if not carefully designed and testedCorrect.

Cross-object formulas contribute to:

SOQL query depth limits

CPU time limits

Formula size complexity

Relationship depth limits

In CPQ/Billing, where Quote and Quote Line processing already push platform limits, too many formula fields can cause:

Calculation failures

Invoice/Order creation errors

Apex limit exceptions

Salesforce documentation warns against heavy formula usage for precisely these scalability concerns.

❌ E. Formula fields are editable, after calculation a user/process can overwrite the valueIncorrect.

Formula fields are never editable by users or automation.

Their values are dynamically calculated from their formula expressions.

Therefore, this option is not a valid risk.

Salesforce CPQ scoping guidance always starts with Business Process Mapping to understand:

Lead → Opportunity → Quote → Contract → Order → Billing → Renewal lifecycles

How CPQ/Billing should support the business

Products, documents, e-signature, and order management all come after process mapping.

Thus A is correct.