2026-06-19 · Updated 2026-08-18 · FieldRat

Salesforce custom field limit: caps by edition and how to free headroom

Salesforce caps custom fields per object — 500 on Enterprise, 800 on Unlimited and Performance, less on lower editions. Once a busy object gets close, the fix isn't "ask Salesforce for an exception" — the cap can't be raised. It's finding the fields nobody's used in years and retiring them first.

Why orgs hit the limit before anyone notices

The limit creeps up slowly. A field gets added for a campaign that ended two years ago. A picklist gets added for a record type that was deprecated last year. An integration field stays after the integration it served got replaced. None of these show up as a problem until someone tries to add a field for a real project and gets blocked by the cap on Account or Opportunity — usually the two most field-heavy objects in any org, and usually mid-deploy when it's least convenient to find out.

Can you increase the custom field limit on Opportunities?

No — and Opportunity is where most orgs hit the wall first. The cap follows your edition (500 on Enterprise, 800 on Unlimited and Performance) and Salesforce Support won't raise it, unlike some other limits. Opportunity fills up fast because CPQ, forecasting, marketing attribution, and revenue-intelligence packages all add their fields there on top of yours.

What actually works when Opportunity is near the cap:

• Retire unused fields first. Most mature Opportunity objects carry dozens of fields at 0–2% population from ended campaigns and replaced processes.
• Move reporting-only attributes off the object. Data that only feeds a dashboard can live on a related custom object instead of consuming Opportunity headroom.
• Check where package fields count. Fields from AppExchange certified managed packages draw on a separate allowance — fields from uncertified packages count against your edition limit like your own.
• Upgrade edition only as a last resort. Enterprise to Unlimited moves the cap from 500 to 800, but if field sprawl caused the problem, the new headroom goes the same way.

Step 1: Know how close you actually are, per object

Field count alone isn't the full picture — the limit is per object, and it varies by object type and edition (it's lower on objects like Case in some configurations than on Account). You need a per-object view of current field count against that object's actual cap, not a global custom-field count across the org. FieldRat's dashboard tracks field-limit utilization per object so you can see which ones are actually close before you're blocked by one mid-deploy.

Click to enlarge

Step 2: Separate "old" from "actually unused"

A field created five years ago isn't automatically a retirement candidate — it might be the most-used field on the object. Field age tells you nothing about field usage. Run a population check across the object's fields and look for the ones sitting at 0–2% population given the object's record count. Those are your real candidates, regardless of how old or new they are.

Step 3: Check dependencies before retiring anything

Freeing up headroom only works if the fields you retire actually stay retired — not rolled back two days later because a flow broke. Before deleting a low-usage field, scan it against validation rules, flows, Apex, reports, and layouts. FieldRat's Quick Scan covers 11 metadata types in seconds; for fields with any ambiguity, Deep Scan extends to 23 metadata types via a metadata ZIP, including Apex and flow references that Setup's native dependency view misses.

Step 4: Retire in batches, not one field at a time

If an object is near its cap, you likely need to retire more than one field to get meaningful headroom back. Score every candidate's deletion risk (0–100, based on usage, dependency breadth, and whether any dependency hit lands in a critical metadata type), sort by risk, and clear the lowest-risk batch first. That gets headroom back fast without touching anything a flow or integration still depends on.

The limits people hit next

Three limits sit right behind this one, and they catch the same teams for the same reason: the objects that run out of field headroom are the objects everything else is attached to. Worth knowing before you plan around any of them.

Custom object limits

“Move it to a related custom object” is the standard escape from a full object, and it works — but custom objects have their own per-edition cap, and an org that has been solving field pressure this way for years can be closer to it than anyone realises. Splitting an object also moves the cost rather than removing it: you now carry a relationship, a page layout, sharing settings, and a report type that did not exist before.

We are deliberately not printing an object-count table here. The per-edition numbers are widely republished across vendor blogs and we could not confirm the current values against Salesforce’s own documentation — its allocation pages render client-side, so the figures circulating are copies of copies. Your org shows you the real answer: Setup → Company Information lists custom objects used against your allowance. Read it there rather than trusting any blog, including this one.

Field history tracking limits

Standard field history tracking covers 20 fields per object, and Salesforce retains that history for about 18 months in the UI and 24 months via the API. This bites the same objects for the same reason a field cap does: Opportunity and Case accumulate the most fields, and they are also the objects where an auditor or a revenue team wants history on more than 20 of them.

There is a cleanup angle worth knowing. Tracking slots are a fixed budget, and orgs routinely spend them on fields that stopped being used years ago — a tracked field sitting at 0% population is a wasted slot. The same population data that identifies retirement candidates identifies tracking slots you can reclaim without deleting anything, which is a much easier internal conversation than deletion.

Field Audit Trail, and the number nobody agrees on

Field Audit Trail is the paid add-on that extends the above. Two things about it are consistent everywhere and safe to plan around: history is archived into a big object called FieldHistoryArchive rather than purged at the retention cliff, and it is retained until you delete it rather than ageing out.

The field count is a different story, and we would rather say so than pick one. Salesforce’s own materials disagree with each other. Its help documentation states 200 tracked fields per object; its own Field Audit Trail datasheet says 60; Trailhead’s configuration walkthrough describes selecting up to 50. Vendor blogs repeat all three with equal confidence, which is how a number like this survives being wrong for years.

Checked August 2026. If your design depends on the exact ceiling, do not take it from any article — enable tracking on a sandbox object and add fields until Salesforce stops you. That takes ten minutes and gives you the number for your org, on your current release, which is the only version of it that matters.

Salesforce custom field limit FAQ

Related: How to find unused fields in Salesforce, or see how FieldRat compares to other tools on the comparison hub.