System Overview
A System Overview is a Setup page in Salesforce that gives administrators a single, high-level summary of how much of the org's resources are in use compared to the limits the edition allows.
Definition
A System Overview is a Setup page in Salesforce that gives administrators a single, high-level summary of how much of the org's resources are in use compared to the limits the edition allows. It groups usage into sections such as Schema, API Usage, Business Logic, User Interface, Most Used Licenses, and Portal Roles, so you can spot a resource filling up before it becomes a problem.
The page reads from the same allocations that govern the platform, then shows each metric as a current count next to its ceiling. You reach it from Setup by typing System Overview into Quick Find. It is available in both Lightning Experience and Salesforce Classic, in every edition except Personal Edition.
How the System Overview page reads your org
What the page is for
The System Overview page answers one question fast: is this org running out of anything? Salesforce sets allocations on dozens of resources, and many of them are tied to your edition rather than something you can raise on demand. Custom objects, custom fields, data storage, daily API requests, Apex code size, and active workflow rules all have ceilings. The platform tends to tell you when you have crossed a limit, not when you are getting close, so a deployment can fail mid-release because a counter quietly filled up. This page puts the most important counters in one view so the warning arrives early. Each metric shows a current number next to the maximum the org allows, which turns a vague worry into a concrete figure you can plan around. It is read-only reporting, not a control panel, so nothing here changes configuration. Think of it as the dashboard light that tells you to check capacity before the project that needs that capacity is already in flight. Reaching the page takes one step: open Setup and type System Overview into Quick Find.
The Schema and API Usage sections
The Schema section tracks the building blocks you create rather than the standard ones Salesforce ships. It reports how many custom objects exist against the edition cap, how many custom settings objects you have defined, and how much data storage the org is consuming. Because custom objects and the fields on them are some of the easiest limits to hit during a busy build season, this is often the first section an admin checks before approving a new project. The API Usage section reports API Requests, Last 24 Hours, shown as a running total over the preceding 24 hours with the Daily API Request Limit displayed alongside it. Integrations, middleware, and data loads all draw from that same daily pool, so a single chatty connector can consume a surprising share of it. Watching this number helps you catch a runaway integration before it locks out the rest of your traffic for the day. If you need a finer breakdown of storage by object and row count, that lives on the Storage Usage page, while Company Information carries the org-wide storage totals.
Business Logic and User Interface sections
The Business Logic section is where automation and code show their footprint. It reports the number of Apex triggers, the number of Apex classes, the percentage of the org's Apex code limit that is used, and the count of workflow rules. The code percentage matters because Apex is capped by total characters across the org, and a large managed package or years of custom development can push that figure higher than teams expect. Seeing it climb is a signal to refactor or to review what can be removed. The User Interface section covers what users actually interact with. It reports counts for custom apps, Site.com and Force.com Sites that are active, Visualforce pages, and tabs. None of these are usually the first thing to run short, but a heavily customized org with many internal apps and public sites can approach them. Both sections share the same value as the rest of the page: they replace guesswork with a number. Instead of assuming there is plenty of headroom for the next automation or the next branded site, you can confirm it in seconds before committing to the work.
Licenses and Portal Roles
The Most Used Licenses section, sometimes shown simply as Licenses, lists license types with the number used set against the number available. This is a quick pulse on whether you are about to run out of seats for a given license, which is a procurement conversation rather than a cleanup task. For the full contractual picture, including usage-based entitlements and what you are entitled to buy, you pair this view with Company Information and Manage Subscription. The Portal Roles section tracks the roles created for Experience Cloud and legacy portal users against the org allocation. Portal roles deserve special attention because the limit is org-wide and the roles are created automatically as partner and customer accounts are enabled, so the count can grow without anyone deciding to grow it. Salesforce treats this metric more cautiously than the others. The page surfaces a warning at 95 percent of most limits, but for portal roles the warning appears earlier, at 75 percent, because the ceiling is harder to raise and reorganizing portal roles after the fact is disruptive. That earlier nudge is a deliberate prompt to plan before you are cornered.
Reading the warnings, and configuring them
The page does more than display numbers. When a resource crosses a threshold, Salesforce shows a message at the top of the page so the alert is hard to miss during a routine visit. The default trigger is 95 percent of a given limit, with the earlier 75 percent point reserved for portal roles. Administrators with the right permission can adjust what these messages say through the Configure System Overview Messages setting, which is useful when you want the warning to point your team to an internal runbook or a capacity request process rather than a generic note. Customizing the message turns a passive alert into an instruction your colleagues can act on. One practical caution: a percentage near a ceiling is not the same as a hard stop, and a few limits behave differently from the simple counts shown here, so treat the page as the prompt to investigate rather than the final word. The habit that gets the most value out of it is regularity. A monthly pass during your platform review, scanning each section for anything trending toward its cap, catches the slow-moving problems while you still have room to fix them calmly.
A worked example: the field-count squeeze
Picture an org midway through a product launch. The Schema section shows custom field usage on the Account object sitting comfortably below the cap, and the team plans a new project that adds 40 fields to support the launch. A quick look at System Overview during the planning week shows Account fields at 470 of the 500 the edition allows. That single number changes the plan. Adding 40 fields would blow past the ceiling and stall the deployment, and discovering it mid-release would mean an emergency cleanup under deadline pressure. Instead, the team spends an afternoon auditing the object, finds 25 legacy fields left over from a retired process, and deletes them after confirming nothing references them. Field usage drops to 445, the new fields fit, and the launch ships without drama. The same pattern applies to API requests before onboarding a new integration, to Apex code percentage before a large package install, and to portal roles before enabling a wave of partner accounts. The page did not do the work, but it surfaced the constraint early enough that the work could be planned instead of rushed.
Configure the System Overview warning messages
You cannot create a System Overview page, since every org has exactly one. What you can configure is how its warning messages read, so a colleague who lands on the page during a busy week gets a clear instruction instead of a generic alert. This is set up once and adjusted as your process changes.
- Open the System Overview page
From Setup, type System Overview into the Quick Find box and open it. Scan each section so you know which limits are closest to their ceilings before you write any message.
- Find the message setting
In Setup, search for the Configure System Overview Messages option. This is where you control the text shown when a resource crosses its threshold, so the warning can point to your own runbook.
- Write a message that prompts action
Replace the default note with text that tells the reader what to do next, such as linking an internal capacity-request page or naming who owns the cleanup. Keep it short and specific.
- Save and verify
Save the configuration, then confirm the message reads correctly. Revisit it whenever your capacity process changes so the guidance never goes stale.
The fastest route to the page in both Lightning Experience and Salesforce Classic; available in every edition except Personal Edition.
The setting that controls the text of the threshold warnings, so you can route readers to an internal process instead of a generic alert.
Most limits warn at 95 percent of the allocation; portal roles warn earlier, at 75 percent, because that ceiling is harder to raise.
- The page is read-only reporting. It shows usage but does not let you raise a limit or delete the resource that is filling up.
- A few limits behave differently from the plain counts displayed here, so treat a near-ceiling percentage as a prompt to investigate, not a hard guarantee.
- Portal roles can grow on their own as partner and customer accounts are enabled, so the 75 percent warning can arrive without anyone deliberately adding roles.
- Personal Edition does not include the System Overview page, so this guidance applies only to editions that expose Setup limits this way.
Trust & references
Cross-checked against the following references.
- The System Overview PageSalesforce
- System Overview: API UsageSalesforce
Straight from the source - Salesforce's reference material on System Overview.
- System Overview: Business LogicSalesforce
- Configure System Overview MessagesSalesforce
Hands-on resources to go deeper on System Overview.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Why is understanding System Overview important for Salesforce admins?
Q2. What is the primary benefit of System Overview for Salesforce administrators?
Q3. Can a Salesforce admin configure System Overview without writing code?
Discussion
Loading discussion…