2026-06-19 · Updated 2026-07-26 · 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.
Quick answer: the maximum custom fields per Salesforce object
| Edition | Custom fields per object |
|---|---|
| Unlimited, Performance | 800 |
| Enterprise, Developer | 500 |
| Professional | 100 |
| Group, Essentials | 25 |
- The cap is per object, not per org — roll-up summaries and formula fields count toward it; standard fields don't.
- Fields from AppExchange certified managed packages draw on a separate additional allowance on top of your edition limit, up to a hard platform maximum per object.
- The Activity object (Tasks and Events) has its own lower limits — far fewer custom fields than other objects.
- Source: Salesforce Help — Custom Fields Allowed Per Object.
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.
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.
FieldRat tracks field-limit utilization per object, scores deletion risk 0–100, and ships a retirement workflow with audit-ready exports — free, native to Salesforce.
Salesforce custom field limit FAQ
What is the maximum number of custom fields per object in Salesforce?
It depends on your edition: 500 custom fields per object on Enterprise and Developer editions, 800 on Unlimited and Performance, 100 on Professional, and 25 on Group and Essentials. The limit is per object, not per org — an org can hold far more custom fields in total. The Activity object has its own lower limits.
What is the Salesforce custom field limit and what counts toward it?
The custom field limit is the maximum number of custom fields allowed on a single object. Custom fields you create, roll-up summary fields, and formula fields all count toward the per-object cap. Standard fields do not count. Fields installed from AppExchange certified managed packages get a separate additional allowance on top of your edition limit, up to a hard platform maximum per object.
Can you increase the Salesforce custom field limit?
No. The custom-fields-per-object cap is set by your Salesforce edition and Salesforce does not raise it on request — upgrading edition (for example Enterprise's 500 to Unlimited's 800) is the only way the number itself goes up. The practical fix is to retire low-usage custom fields to free headroom — find fields sitting at 0–2% population, confirm nothing depends on them, and delete the lowest-risk batch first.
How do I increase the custom field limit on Opportunities?
You can't raise the per-object cap on Opportunity — it follows your edition limit (500 on Enterprise, 800 on Unlimited/Performance). Opportunity hits the cap early because CPQ, forecasting, and marketing packages all add fields there. To get headroom back: retire unused Opportunity fields first, move reporting-only attributes to a related custom object, and check whether package fields are from certified managed packages (those draw on a separate allowance instead of your edition limit).
How do I find which custom fields are safe to delete?
Run a population check to surface fields at 0–2% usage, then scan each candidate against flows, validation rules, Apex, reports, and layouts before deleting. FieldRat's Quick Scan covers 11 metadata types natively and Deep Scan extends to 23, then scores each field's deletion risk 0–100 so you can clear the safest fields first.
Do I need a full Salesforce org audit or just field cleanup?
They answer different questions. Field cleanup (FieldRat) works the field dimension continuously — usage, dependencies, safe retirement. A full org audit checks everything once: access risk, silent failures, upcoming deprecations, and field debt together. TechParrot, the team behind FieldRat, runs a free 65-check OrgAudit (techparrot.io/products/orgaudit) — a common pattern is OrgAudit first to diagnose, FieldRat after to keep fields clean.
Related: How to find unused fields in Salesforce, or see how FieldRat compares to other tools on the comparison hub.