Governor limits: when your promo logic hits an invisible wall

Because Salesforce enforces hard per-transaction ceilings that no support ticket can lift. A synchronous Apex transaction gets 100 SOQL queries, 50,000 query rows, 150 DML statements, 10 seconds of CPU and 6MB of heap (as of February 2026), and the documentation says plainly these cannot be raised by Salesforce Support. Flow inherits the same shape. Your promo and loyalty logic has to fit the platform's budget, not your business rules.

What breaks first when a promo rule scales?

The failure is undramatic. A loyalty accrual rule that evaluated cleanly against a ten-line test order throws System.LimitException: Too many SOQL queries: 101 the first time a distributor submits a real order with three hundred lines. Nothing was wrong with the logic. The rule ran one query per line inside a trigger that fired once for the whole batch, and line 301 crossed a ceiling that had been invisible until that exact moment.

That is the defining trait of governor limits: they are silent until they aren't. Unit tests pass, the pilot demo sails through, and then a genuine trade order — hundreds of SKUs, returnable-container lines, multi-tier pricing — tips the same transaction past 100 queries or 150 DML statements. The order does not partially save. The whole transaction rolls back, and the buyer sees an error that means nothing to them.

Which limits bite B2B commerce and loyalty first?

Four of them do most of the damage. Per the official Apex governor limits documentation (as of February 2026), a single synchronous transaction is capped at these ceilings:

Flow does not escape any of this. As documented in the Salesforce Ben Flow limits guide, a flow interview is bound to the same 150 DML statements and roughly 100 data elements per transaction — and, the one that quietly wrecks loyalty math, the same record can be updated a maximum of 12 times in a single transaction (as of February 2026). Rebuild a member's point balance through twelve chained updates and the thirteenth throws.

Why can't you just raise the ceiling?

You can't, because the ceiling is the product. Salesforce is multi-tenant: your Apex shares infrastructure with every other tenant, and governor limits are the mechanism that stops one customer's runaway loop from starving the neighbours. The documentation is blunt about the recourse — these limits, it notes,

cannot be increased by Salesforce Support

That single clause reframes the whole engagement. Elsewhere in enterprise software a hard ceiling is a negotiation: file a ticket, buy a bigger tier, capacity appears. Here there is no tier. No amount of budget, escalation or partner status moves the number. The limit is fixed by design, and any architecture that assumes otherwise is already broken — it just hasn't met a big enough order yet.

Why does beverage route-to-market hit the wall faster?

Because the orders are large and the work per line is heavy. A convenience-store or on-trade order in a route-to-market flow is not a two-item basket; it is a full range replenishment — dozens to hundreds of SKUs, each carrying returnable-container accounting, volume-and-mix promotions, and loyalty accrual that often depends on the whole basket rather than a single line. Every one of those concerns wants to run a query or write a record, and they all share one transaction budget.

Then multiply by bulkification. Integrations post orders in batches: a nightly settlement or a distributor's ERP might push 200 orders in one API call, and Apex triggers fire once for the whole set, not once per order. Now the 100-query and 150-DML ceilings are shared across 200 orders at once. Logic that was comfortable at one order per transaction is suddenly 200 times too expensive, and nobody wrote a bad line of code to get there. It is the same class of problem as the point where 2,000 buyer groups make entitlement search silently break — a fixed platform number that ordinary business growth walks straight into.

Where does this trap loyalty logic specifically?

Loyalty is the worst-hit, because its math is inherently iterative. Points accrue per line, then adjust for basket-level bonuses, then reconcile against tier thresholds, then sometimes re-post after a promotion resolves — and each of those steps wants to touch the same member record. The 12-updates-per-record cap turns a naive "recalculate until stable" loop into a landmine. Buying your way out of it doesn't help either: we've written before about how an open-source loyalty engine quietly stops being open once you need to bend it, and a proprietary engine sitting on Apex just hands you a different fixed ceiling. Either way the constraint is the runtime, not the vendor's feature list.

So how do you build for a fixed budget?

The direction out is always the same: get the heavy work off the synchronous transaction. Split bulk logic into asynchronous, resumable units, push cross-order promo and loyalty evaluation onto an event bus where each order is its own bounded piece of work, and treat 100 queries, 150 DML and 10 seconds as fixed inputs to the design rather than a wall to argue with. We build our route-to-market suite on exactly that event-driven shape, so a 300-line order and a 200-order batch are the same small unit of work repeated — never one transaction fighting a platform budget.

These limits are not going to loosen; multi-tenant economics only push the other way. And as more real-time, AI-driven pricing and promo logic gets pulled toward the order-capture path — carrying its own per-conversation cost surprises — the synchronous transaction only gets more crowded. The teams shipping reliably next year will be the ones who designed for a fixed budget from the first order line, not the ones still holding out for a support ticket that is never going to come.