The Review Board Rejects a Hand-Built Pricing Engine
Business asks for real-time pricing on quotes: 45,000 quotes a month, three regions, 120 pricing rules that change roughly monthly, and a target save time under two seconds. The delivery team proposes an Apex before-save trigger on QuoteLineItem that runs twelve SOQL queries and six DML statements per line, iterating line by line, backed by six new custom objects holding rule metadata, with no caching. They also plan to call an external pricing microservice synchronously from the trigger. Licensing: 400 sales users; packaged pricing licences were quoted at a cost the sponsor calls unacceptable this year. The architecture review board meets in ten days and has already flagged governor-limit risk, testability and a missing rollback story. Two reviewers question whether the rules belong in Salesforce at all. The sponsor wants a decision memo, and a recommendation that survives audit and a future migration to a packaged pricing tool.
1. Frame the options and recommend one, making the decision rule explicit rather than asserting a preference.
Read the worked answer
Three credible options. First, in-platform Apex as proposed: fastest to start, no licence cost, but fourteen operations per line across a fifty-line quote will breach SOQL and DML limits on day one, and a synchronous external call inside a database transaction is unworkable. Reject it in that form; a bulkified, cached, metadata-driven variant is possible but expensive to build and to change monthly.
Second, packaged pricing. Best fit for rule volatility and auditability, but the licence cost is a real constraint and the sponsor has said no this year.
Third, compute outside Salesforce: the pricing service owns rule evaluation, Salesforce owns the quote, the approval trail and an immutable price snapshot per line. Salesforce calls the service asynchronously or via a pre-quote pricing call, caches results by product/region/date, and stores the outcome. No licence cost, rules change on the service's release cycle rather than requiring Salesforce deployments, and the snapshot makes the audit story concrete.
The decision rule: when rule volatility is high (monthly), change frequency exceeds the Salesforce deployment cadence, and compute is rule-heavy rather than data-heavy, move compute out and keep the transaction and audit inside Salesforce. That rule also survives migration - if a packaged tool is licensed later, the snapshot and interface remain valid.
2. The board's specific objections are governor limits, testability and rollback. Answer each as it applies to your recommendation.
Read the worked answer
Governor limits: the recommendation removes the per-line loop from the transaction. A single callout carries a composite payload for all lines on the quote, so you spend one callout rather than fifty, and the calculation no longer performs DML on metadata objects inside the save. Cache jurisdiction and product rates keyed by effective date so repeated lookups resolve locally. Where a calculation must stay in Apex, bulkify: one query over all lines, in-memory rule evaluation, one DML. Show measured numbers from a load test, not assertions - the board will accept evidence and discount slides.
Testability: the external service is mocked behind a named credential and an interface, so unit tests cover the orchestration, error mapping and caching without a live endpoint. Rule logic lives where it has its own test suite and version history. Snapshot fields give assertions on outcomes rather than on internal call counts.
Rollback: this is the weakest part of any synchronous design and the honest answer is that callouts are not transactional. Persist the quote in a Pricing Pending state, treat the price response as an event that either completes or fails visibly, and define compensating actions: mark the line, notify the owner, allow repricing without duplicating the quote. A feature flag can route traffic back to manual override if the service degrades. State the residual risk explicitly - a period of pending quotes during an outage - and get the business to accept it in writing rather than hiding it.
3. What should the decision memo contain, and how do you handle reviewers who question whether the rules belong in Salesforce at all?
Read the worked answer
The memo should be an architecture decision record: context and constraints (volume, 120 rules, monthly cadence, two-second target, licence constraint, six-week expectation versus realistic delivery), the options considered including the rejected ones and why, the decision rule, the chosen option, consequences both positive and negative, and what would cause the decision to be revisited. Attach the load-test evidence, a cost comparison including build and run cost rather than licence alone, and a data-flow diagram showing where the price snapshot is written and read.
On the reviewers' question: agree with them publicly and show that the recommendation already answers it. The rules do not belong in Salesforce if they change monthly and have no transactional dependency - that is precisely why the evaluation engine moves out while the quote, the approval and the audit snapshot stay in. The reviewers' concern becomes a design principle rather than an objection, which is how you convert a challenge into consensus.
Also record dissent and the residual risks the sponsor is accepting: asynchronous pricing latency, dependency on a service with its own availability, and the integration surface. Name a decision owner, a date and review triggers, such as rule complexity exceeding what the service can version, or a licence becoming affordable.
Finally, separate the six-week question from the architecture question. If the sponsor needs something in six weeks, propose a thin slice - one region, snapshot fields, manual override - delivered inside the target architecture rather than a throwaway build that has to be replaced.