Object Manager, pick an object, then Object Limits. It lists the per-object ceilings with a used count, a maximum and a percentage. Most of them you will never approach. Three of them decide the shape of mature orgs: roll-up summary fields, relationship fields, and custom fields on whichever object your business actually revolves around. Check the page before you design, not after a deployment fails.
What the counters mean
- Custom Fields. Every custom field on the object, including formulas. The ceiling depends on edition, commonly 500 in Enterprise and higher in Unlimited. Formula fields consume the same allowance as stored ones.
- Custom Relationship Fields. Lookups and master-detail together, capped at forty. Master-detail is separately limited to two per object.
- Roll-Up Summary Fields. Twenty-five by default, raisable by Salesforce on request up to a higher figure. Only available on the master side of a master-detail relationship.
- Active Validation Rules. Only active ones count, so deactivating rather than deleting still frees the slot.
- Active Lookup Filters. Five per object, which is low and catches people who lean on filtered lookups for data quality.
- Sharing Rules. A generous total, with a lower sub-limit specifically for criteria-based rules. That sub-limit is the one you hit.
- Record Types, Apex Sharing Reasons, Custom Indexes and a few others, none of which usually cause trouble.
The page shows current usage live, so it is also the fastest way to answer “how many custom fields does Account really have” without exporting metadata.
The counter that surprises people
Deleted fields still count.
When you delete a custom field it goes to the deleted fields area and remains there, consuming its slot, until it is permanently erased or the retention period ends. An org that has deleted sixty fields over two years and never erased any is sixty fields closer to the ceiling than the field list suggests.
Erasing is deliberate and irreversible, so it needs care, but it is the first thing to do when a limit is close. Look at the deleted fields list before assuming you need to remove something people still use.
Which you hit first
Roll-up summary fields. Almost always the first wall, and it arrives early. Twenty-five sounds like plenty until a finance team wants totals by product line, by year and by status on the same parent. The escape routes are asking Salesforce to raise the limit, replacing some roll-ups with a scheduled flow writing to a number field, or accepting that a report is the right tool for a number nobody needs on the record page.
Relationship fields on the hub object. Forty goes quickly on Account or on whatever custom object everything points at. Each new integration wants its own lookup. The fix is design rather than housekeeping: a junction object, or a single lookup with a type field, instead of eight lookups that are mutually exclusive.
Custom fields on Account, Contact and Opportunity. This is a slow problem that becomes urgent suddenly. The pattern is a decade of small requests, each reasonable, with nothing ever removed. When the count passes about three quarters of the limit, start a deliberate field cleanup rather than waiting.
Active lookup filters. Only five, and easy to forget. If you use them heavily on one object you will find the ceiling before you find any of the others.
Getting room back
Erase deleted fields first, because that is free.
Then find fields nobody uses. Salesforce Optimizer reports on unused custom fields, and field usage data plus a search across reports, list views and code tells you what is safe. Mark candidates with the Field Usage classification value rather than deleting immediately, give it a release cycle, then delete.
Some ceilings can be raised by support and some cannot. Roll-up summaries and criteria-based sharing rules are the usual successful requests. Custom field counts are generally not negotiable, so plan as if that number is fixed.
Frequently asked
Do managed package fields count against my limit? Fields from a managed package generally sit outside your org’s custom field count for the object, which is why an installed package can add hundreds without breaking you. Check the Object Limits page for the real number rather than assuming either way.
Does the page show org-wide limits too? No. It is per object. Org-level items such as total custom objects or active flows live in Company Information and the relevant setup pages.
Can I query these limits? Yes, the REST limits resource exposes several org-level limits, and the Object Limits page is backed by data you can reach through the API for automation and monitoring.
What happens when I hit a limit? The save or deployment fails with an explicit error. Nothing degrades silently, which is the one kind thing about this page.
