For a large Enterprise Revenue Cloud (Salesforce CPQ + Billing) implementation, the key themes in all Salesforce delivery guidance and project best practices are:
Governance and change control
Design-first, then build
Raising scope-impacting changes through the Project Manager
Architect accountability for solution integrity, PM accountability for scope/timeline/budget
Let’s walk through why C is correct and why the other options conflict with typical Salesforce CPQ/Billing implementation best practices.
1. Context of the ScenarioYou are in the Build phase and:
You already have a design with:
New information emerges:
Additional pricing logic
External data stores that must be incorporated
Need to modify existing lookup rules
Need to create additional rules
Need API development (integration work)
This is not a cosmetic tweak; it is:
Scope-impacting (new integration/API work, new logic)
Design-impacting (pricing architecture changes)
Potentially timeline and budget impacting
Therefore, this triggers formal change control.
2. Why Option C is CorrectC. Communicate these changes to the project manager who will evaluate the impact to scope, timeline and budget then determine the next course of action
This aligns with standard Salesforce implementation and project governance principles:
Any change that affects scope, complexity, or integration must be raised to the Project Manager (PM)
Project Manager is responsible for:
The PM will:
Evaluate impact with:
Solution Architect (for technical/design impact)
Tech leads / Dev leads (for effort estimation)
Decide:
Whether a Change Request (CR) is needed
How to re-prioritize sprints, adjust backlog
Whether additional budget / time is required
How to communicate to customer stakeholders
This preserves:
Design integrity (Architect still evaluated the solution)
Project discipline (PM governs scope/timeline/budget)
Traceability and documentation (updated design docs, backlog, CRs)
This is exactly how a large enterprise Revenue Cloud (CPQ + Billing) program is expected to run.
3. Why the Other Options Are Not AppropriateA. “Adjust as long as we're in build phase”A. Communication to the customer ongoing adjustment can be made as long as we're in the build phase.
Problems:
Implies uncontrolled scope creep:
“As long as we’re in build, we can just keep adjusting.”
No mention of:
Impact to scope, timeline, budget
Formal change control
Involvement of PM or Architect
In a complex CPQ/Billing implementation, this would:
Break governance
Risk missed deadlines and budget overruns
Create misaligned expectations with the customer
So A contradicts standard methodology and enterprise delivery practices.
B. “Implement then review with the Solution Architect”B. Implement the lookup price rules immediately then review with the solution Architect.
Problems:
Sequence is wrong:
This can cause:
Misalignment with overall pricing architecture
Conflicts with other CPQ/Billing components (e.g., Amendments, Renewals, Billing logic)
Rework if the Architect has a different approach
Still no mention of PM or scope/timeline/budget impact.
This violates both design governance and project governance.
D. “Architect then immediate implementation (no PM)”D. Consult with the solution Architect first who will expedite the updates to the design documents, then implement the changes immediately.
This is closer, but still incomplete:
Good:
You involve the Solution Architect.
You talk about updating design documents.
But:
No involvement of the Project Manager.
No consideration of:
Impact to scope
Impact to timeline
Impact to budget
For “large Enterprise Revenue Cloud” projects, Architect ≠ PM:
Architect owns technical solution integrity
PM owns project plan, change control, stakeholder approvals
So D ignores formal change management which is critical at enterprise scale.
E. “If low effort, just do it; else next sprint”E. Gather more details, if it requires a low level of effort then implement immediately before starting the next sprint. Otherwise complete on the subsequent sprint.
Problems:
Consultant is unilaterally deciding based on “low effort”:
This might be okay for minor cosmetic or non-functional changes in a small project, but:
Here we have:
Complex pricing
Multiple lookup price rules
External data store integrations
API development
This is never “just low effort”.
For a large enterprise Revenue Cloud implementation:
This bypasses governance, change control, and approvals.
So E promotes ad hoc scope changes, which is against standard practice.
4. How This Ties Back to Salesforce CPQ & Billing Best PracticesIn Salesforce CPQ and Billing implementations, especially when dealing with complex pricing logic and external integrations:
Complex Pricing (Lookup Price Rules):
Changes can affect:
Quote calculation performance
Sequential dependencies with Price Rules, Discount Schedules, QCP, Billing logic
May cause downstream issues in:
Orders, Invoices, Revenue Schedules, Amendments, Renewals
External Data Stores & API Development:
Introduces:
New integration patterns
Error handling, retries, timeouts
Security and governance requirements
Impacts:
Technical design
Test strategy (SIT, UAT, performance testing)
Possibly non-functional requirements
Because of that, Salesforce project documentation and implementation guidance emphasize:
Raising such changes via Project Manager
Having the Solution Architect assess and update:
Solution design
Integration architecture
Managing it formally as a change request if it affects:
This is exactly what Option C describes at the right level of responsibility.
