Salesforce Loyalty limits you can only raise by support case

Salesforce Loyalty Management can run a national programme, but two of its scaling ceilings are not settings you control. Raising the core extendable limits means filing a case with Salesforce's Feature Activations and Limits Team; the documentation itself points the batch route there when it stops scaling. And real-time accrual executes on-platform inside the standard Apex governor envelope — 100 SOQL queries and ten seconds of CPU per transaction. Past a few million members, growth becomes a support ticket.

What does an "extendable" limit actually commit you to?

Salesforce splits its ceilings into fixed limits and extendable ones. An extendable limit is still a cap; the difference is that you can ask for it to be lifted. The Loyalty Management limits reference does not treat this as an obscure edge case. It tells administrators that when configured batch jobs stop scaling to their business requirements, the remedy is to escalate:

request an increase of extendable limits ... through the Feature Activations & Limits Team

Read that as an operating model, not a footnote. Headroom is not a dial in your admin console; it is a number held by a team on the vendor's side, granted case by case. You cannot provision for a festival weekend by editing a configuration value the way you would scale a queue — you raise a case and wait for someone to approve it. The official limits page is candid that the batch path exists precisely for volumes the defaults do not cover, which is another way of saying the defaults assume a smaller programme than the one a national brewer actually runs.

Why does real-time accrual run into governor limits?

The alternative to batch is real-time accrual, and it carries its own ceiling. Accrual logic runs on-platform, executing as Apex inside the same governor envelope every other synchronous transaction in the org shares. Per the Salesforce developer limits reference, one synchronous transaction gets 100 SOQL queries, 10,000 milliseconds (ten seconds) of CPU, 150 DML statements, and may retrieve at most 50,000 rows. Asynchronous work raises the SOQL and CPU allowances but not the underlying model.

A single accrual event is rarely a single query. It resolves the member, walks the applicable accrual rules, evaluates tier, updates one or more balances, and may issue a voucher — several SOQL reads and several DML writes each. Multiply that by the concurrency of a promotional burst and the constraint is the platform envelope, not the hardware underneath it. Loyalty's business APIs are convenient, but they resolve down to this same shared budget.

The synchronous ceilings a real-time accrual competes for, per the developer limits reference:

What is the Summer '24 release note admitting?

You can read a platform's pressure points from its release notes. Summer '24 (version 244) shipped a Loyalty change whose title is the entire argument:

Execute More Business API Requests with Expanded Limits

The release note is a straightforward improvement, and raising a limit is a good thing to do. But a feature whose headline benefit is that a cap you were hitting is now higher is also an admission: the previous cap constrained real customers, the ceiling binds at scale, and it moves only when the vendor decides to move it. That is the same dynamic as a platform that sets your upgrade cadence for you — the forced-update treadmill where the vendor, not your release plan, holds the calendar.

Where does this bite a route-to-market loyalty programme?

Beer loyalty at national scale is spiky by design. Match days, festivals, a heatwave, a returnables-linked bonus point — the moments you most want to reward members are exactly the concurrency spikes that press against the real-time envelope, and the batch fallback is the route the documentation already told you to escalate. So you plan capacity around a figure you do not own, and you cannot fully load-test your way to confidence, because the extendable limit is whatever the vendor last granted, not a number in a specification.

We have seen this shape in loyalty specifically. It is the through-line of a loyalty platform postmortem where the recurring cost was the custom engineering needed to make the product do ordinary things at volume, and it rhymes with the broader habit of holding capability behind a commercial gate — the features behind the enterprise gate. The mechanism differs; the position is identical. Your scale is contingent on someone else's queue.

To be fair to the model: on a multi-tenant platform, extendable limits are not unreasonable. Someone has to stop one tenant's promotion from starving its neighbours, and a support-gated increase is a legitimate safety valve. The awkward part is not that the valve exists. It is that programme growth — the single thing a loyalty roadmap is built to produce — is what routes through it.

So what changes the equation?

Owning the accrual engine. When points maths runs on an event bus you control, throughput is a scaling decision you make — partition the stream, add consumers — rather than a case you file and wait on, while the SAP financial core stays the system of record for the points liability. The ceiling stops being a number someone else grants you and becomes one you raise yourself.

The programmes that absorb the next wave of member growth will be the ones designing for the spike now, before a match-day surge quietly converts a marketing campaign into a support ticket. The extendable-limit model holds right up to the point where your ambition outruns the vendor's queue — and a loyalty programme that is working is, by definition, built to keep outrunning it.