The short version: the character count you can see in the editor and the compiled size that actually errors are two different numbers, and only one of them is visible to you. Formulas are capped at 3,900 characters and 4,000 bytes when saved, but the limit that produces “Compiled formula is too big to execute” is 5,000 bytes when compiled, and compiled size includes the full expansion of every field your formula references. A 400-character formula can fail it.
Three limits, one of them invisible
| Limit | Documented value | Can you see it before you hit it? |
|---|---|---|
| Formula length | 3,900 characters, including spaces, return characters, and comments | Yes — count what you typed |
| Save size | 4,000 bytes when saved | Roughly — multibyte characters cost more than one byte |
| Compile size | 5,000 bytes when compiled | No. There is no counter anywhere in Setup |
The error you get names a number that has no relationship to anything you typed:
Compiled formula is too big to execute (13,974 characters). Maximum size is 5,000 characters.Note the mismatch in wording — the message says characters, the documentation states the limit in bytes. Don’t try to reconcile them. Treat that 13,974 as an opaque score you need to push below 5,000, because that is the only reading of compiled size the platform will ever give you.
Why compiled size inflates without you touching the formula
The mechanism is stated plainly in Salesforce’s own tip sheet on reducing formula size: each reference to another field adds that field’s compile size to your formula. When the referenced field is a plain Number or Text field, that cost is trivial. When it’s another formula field, you are inlining that formula’s entire compiled form into yours, and if that formula references a third formula field, you inherit that too.
This gives you the failure mode that confuses everyone. A formula that saved fine last year suddenly refuses to save today, and you didn’t change it. Somebody else extended a formula field three levels down your dependency chain, and your compiled size went up with it. Compile size is transitive, and nothing warns the person making the change downstream.
Cross-object references inflate for a different reason: the formula compiles into a query, so each hop adds query structure rather than just characters. And not all functions compile equally. The tip sheet singles out date handling — DATE() and MONTH() generate large queries, which is why a formula that looks like simple date arithmetic can be the heaviest thing on the object.
Reduction techniques, in the order I’d try them
1. Eliminate repeated references, not just repeated text
Every occurrence of a referenced field costs its compile size again. So the win comes from restructuring so the expensive reference appears once, not from making the text shorter. Pull the frequently referenced field outside the branching:
/* Expensive: Account.Owner.Region__c compiled four times */
IF(ISPICKVAL(Type, 'New'), Account.Owner.Region__c & '-N',
IF(ISPICKVAL(Type, 'Renewal'), Account.Owner.Region__c & '-R',
IF(ISPICKVAL(Type, 'Upsell'), Account.Owner.Region__c & '-U',
Account.Owner.Region__c & '-X')))
/* Cheaper: compiled once, suffix chosen separately */
Account.Owner.Region__c & '-' &
CASE(Type, 'New', 'N', 'Renewal', 'R', 'Upsell', 'U', 'X')2. CASE() instead of nested IF(), and use its default argument
When you’re branching on one value, CASE() evaluates that value once where nested IF() re-states the comparison every level. Use the final argument as the default rather than adding a last IF() for the fallthrough — that’s one fewer condition compiled.
3. Understand what a helper formula field does and doesn’t do
This is where most advice on this error is wrong. Moving a repeated sub-expression into a second formula field and referencing it reduces the length of the parent formula, which fixes the 3,900-character error. It does not necessarily reduce compiled size, because referencing that helper inlines its compile size — four references to a helper cost roughly what four inline copies cost.
What reliably reduces compiled size is referencing a field that stores a value instead of deriving one: a Number, Text, or Checkbox field populated by a before-save flow. The parent formula then carries one cheap field reference instead of an expanded expression. The tip sheet’s own suggestion to set values in custom fields through automation is exactly this idea.
The tradeoff is not small, so decide with it in front of you. You give up real-time accuracy. The stored value is only as current as the last time the flow ran. You take on a backfill for every existing record, and a second backfill any time the logic changes. And the field can go stale invisibly if a data load bypasses your flow’s entry conditions. In exchange you get a formula that compiles, and usually a faster one.
4. Cut cross-object hops, and watch the separate relationship ceiling
Each hop through a relationship compiles into query structure. Two hops to fetch a value that a flow could stamp on the record is often the whole problem. There’s also a distinct limit here that has nothing to do with compile size: 10 unique relationships per object in cross-object formulas, counted cumulatively across all formula fields, rules, and lookup filters on that object. You can be comfortably under 5,000 bytes and still hit it, and the error names spanning relationships rather than size.
5. Reconsider long picklist mappings
A CASE() over a 25-value picklist is 25 compiled comparisons plus 25 string literals, forever, in every formula that needs the mapping. The tip sheet suggests replacing large picklists with a lookup to a record that holds the value. A custom metadata type or a lookup to a small configuration object moves the mapping out of formula space entirely and makes it editable without a formula change: at the cost of a relationship and, if you need it in a formula, another hop.
How to actually measure it
There’s no compiled-size counter in Setup, so the working method is crude and effective: save the formula, read the number in the error, remove one reference, save again, and see how far the number moved. Two or three iterations tell you which reference is carrying the weight, and it’s frequently not the one you’d guess.
Do this in a sandbox on a scratch field, not on the live formula. Every failed save on a real field is fine, but every successful save on a formula field on a large object queues a recalculation, and you don’t want four of those in an afternoon.
Where else this limit applies
Anything the platform compiles from formula syntax is subject to size limits, not just formula fields: validation rules, field update formulas, default values, and formula resources in flows are all compiled. The failure looks identical and the diagnosis is the same. What differs is your escape route: a validation rule can usually be split into two rules, where a formula field returning one value cannot be split at all.
Frequently asked
Does the number in the error mean my formula is 13,974 characters long?
No. Your formula is under 3,900 characters or it wouldn’t have got that far. The number is the compiled size, which includes the expansion of every referenced field. Treat it as a score to reduce, not a character count.
Do helper formula fields fix a compile size error?
Sometimes, and not for the reason people think. They reliably fix a length error. They fix a compile size error only when the restructuring means the expensive expression is now referenced once instead of many times. A stored field populated by automation fixes it dependably.
Can I see the compiled size before I hit the limit?
Not through Setup. The only reading available is the number in the error message, which means you have to fail a save to learn where you stand. Build near the limit deliberately in a sandbox so you know your headroom.
Can Salesforce raise the compile size limit for my org?
The documented limit is 5,000 bytes and I’m not aware of it being adjustable. Plan on restructuring rather than on a support case.
Does this apply to validation rules too?
Yes. validation rule formulas are compiled the same way and hit size limits the same way. The advantage is that you can usually split one rule into two, which is not an option for a formula field.
Why did a formula that saved last year start failing now?
Because compile size is transitive. Someone edited a formula field that yours references, or a field further down the chain, and their extra logic is now counted inside your compiled size. Find the referenced formula fields and check their edit history in the Setup Audit Trail.
Reference: Reducing Your Formula’s Compile Size and Reducing the Length of Your Formula, Tips for Reducing Formula Size, Salesforce Developers; Formula Field Limits and Restrictions and Tips for Building Cross-Object Formulas, Salesforce Help.
