Settings
A setting in Salesforce is an individual configuration option in the Setup menu that controls how the platform, a feature, or the user experience behaves for the whole org.
Definition
A setting in Salesforce is an individual configuration option in the Setup menu that controls how the platform, a feature, or the user experience behaves for the whole org. The word "Settings" (capitalized) usually refers to the broad family of these pages that administrators open from Setup to turn capabilities on, define policies, and tune default behavior without writing code.
Settings are grouped into sections such as Company Settings, Security, User Management, Feature Settings, and platform tools. Each page owns a narrow slice of behavior, like the fiscal year, password rules, or whether a Sales feature is active. Most settings are org-wide and declarative, which is why they sit at the center of nearly every admin task.
How settings are organized and used in Setup
Where settings live in the Setup tree
Every setting is reached from the Setup menu, and Salesforce documents that all setup options are available there. In Lightning Experience you open it by clicking the gear icon, then selecting Setup (or Open Advanced Setup when Quick Settings is on). The left pane of Setup is a tree, and settings are filed under broad headings so related options sit together. Common groupings include Administration, Company Settings, Security, Users, and Feature Settings, with platform tools like custom code and the API in their own area. Each leaf in the tree is a single page that controls one slice of behavior. For example, Company Information holds org-wide details, Session Settings governs how logins time out, and the various Feature Settings nodes switch product capabilities on or off. Because the tree is deep, browsing it top to bottom is slow. Most admins treat the tree as a map of categories rather than the primary way to reach a specific page. Knowing which heading owns a setting still helps when you are exploring a feature you have not configured before.
Finding a setting fast with Quick Find
The practical way to reach a setting is the Quick Find box at the top of the Setup sidebar, not clicking through the tree. You type the first few characters of a page name, and matching pages appear as you type, so "sess" surfaces Session Settings and "pass" surfaces Password Policies. This search matches page names, which is why knowing the official name of a setting matters more than memorizing its location. Salesforce renames and reshuffles the tree across releases, but Quick Find usually still finds the page by name. Objects are a separate path. Most object-level configuration lives in Object Manager, reached from the top of Setup, where you pick an object and then a customization like fields, page layouts, or validation rules. So a rough rule holds: org and feature behavior comes through Quick Find, while object behavior comes through Object Manager. Getting comfortable with both is the difference between hunting for ten minutes and landing on the right page in seconds. New admins should practice Quick Find early.
Org settings versus personal settings
Not everything in Salesforce that is called a setting is org-wide. There is a clear split between settings that affect the entire org and Personal Settings that affect only the individual user. Org settings, the kind covered in Setup under Company Settings or Security, change behavior for everyone and almost always require an administrator. Personal Settings, reached from your avatar by choosing Settings (sometimes shown as My Settings), let a single user adjust their own preferences. Those include things like email signatures, language and time zone, calendar display, and personal login details. Changing a personal setting never alters another user's experience, while changing an org setting can affect thousands of records and people at once. This distinction matters for support and training. When a user reports that a feature "looks different," the fix is often a personal setting on their own profile rather than an org change. Admins should keep the two mental buckets separate so they edit the right scope. Touching an org setting to solve one person's preference is a common and avoidable mistake that creates wider side effects.
Why a single setting can reshape the whole org
Settings carry weight far beyond their small UI. Because most are org-wide, one toggle can change behavior for every user, record, and integration at once. Turning on a Feature Settings option might expose new fields and automations across the platform. Tightening Session Settings can force everyone to log in again, and a stricter password policy applies to all users at their next reset. That reach is the point of settings, but it also makes them risky to change casually. The safe pattern is to read the help page for a setting, understand its blast radius, and test the change in a sandbox before touching production. Many settings interact, so security, sharing, and feature toggles should be reasoned about together rather than one at a time. A change that looks isolated can have downstream effects on reports, list views, or API calls that other teams depend on. Treat each setting as a small lever on a large machine. The habit of pausing to ask "who and what does this touch" prevents most of the surprises that follow a quick Setup edit.
Tracking who changed what
Settings change over time, and Salesforce records many of those changes in the Setup Audit Trail. The audit trail logs administrative changes made in Setup, including the date, the user who made the change, and what was changed. You reach it from Setup by searching for View Setup Audit Trail in Quick Find. It is the first place to look when a feature suddenly behaves differently and nobody remembers adjusting it. In larger orgs with several admins, the trail is the record of truth for governance and for passing security reviews. It captures recent changes and lets you download a longer history, so you can correlate a behavior shift with the exact edit and person behind it. The trail does not capture everything, and it is not a substitute for a real change-management process, but it is the built-in safety net. Pairing the audit trail with a habit of documenting why a setting was changed turns a list of edits into a story your team can follow. For any org past a handful of users, checking the trail should be a reflex during troubleshooting.
Settings as metadata you can move and deploy
Most settings are not just clicks in a browser. They are metadata, which means they can be packaged, version controlled, and deployed between environments. A configuration you build in a sandbox can move to production through change sets or a metadata-based pipeline rather than being retyped by hand. This is what lets teams develop safely, since you can prove a settings change works in a lower environment before it reaches users. Treating settings as metadata also supports backups and audits, because the definitions live in files you can compare across releases. Not every setting is fully deployable, and some org-level values are environment specific, so a deployment plan should confirm which settings travel and which must be set per org. Still, the mental model is powerful. When you change a setting, you are editing a piece of your org's configuration that has a definition behind it, not flipping a one-off switch. That framing pushes teams toward repeatable, reviewable changes instead of ad hoc edits in production, which is exactly the discipline larger Salesforce programs need as they grow.
How to find and change a setting in Setup
Settings are configured, not created as records. The flow below shows the general path to find any settings page in Setup, change it safely, and confirm the change, using Session Settings as a concrete example.
- Open Setup
In Lightning Experience, click the gear icon in the top right and choose Setup. If your org uses Quick Settings, choose Open Advanced Setup to reach the full Setup tree.
- Find the page with Quick Find
In the Quick Find box at the top of the left sidebar, type the first few letters of the page name, such as "session". Select the matching page, for example Session Settings, when it appears.
- Review before you change
Read the on-page help and confirm the setting is org-wide. Note who and what it affects, since most settings change behavior for every user and record at once.
- Edit and save
Adjust the option, then save. For high-impact pages, make the change in a sandbox first and validate it before repeating the edit in production.
- Confirm in the Setup Audit Trail
Search Quick Find for View Setup Audit Trail to confirm your change was logged with your name, the date, and what changed.
The search field at the top of the Setup sidebar that matches page names as you type; the fastest way to reach a specific settings page.
The separate Setup area for object-level configuration like fields, page layouts, and validation rules, reached from the top of Setup.
A non-production copy of your org where high-impact settings should be changed and tested before they reach live users.
The built-in log of administrative changes made in Setup, used to confirm and review who changed which setting and when.
- Org settings and Personal Settings are different scopes; editing an org page to fix one user's preference can affect everyone.
- Many settings apply immediately and org-wide, so a session or password change can force all users to log in again.
- The Setup tree gets reorganized across releases; rely on Quick Find by page name rather than a memorized menu path.
- The Setup Audit Trail does not capture every change and is not a replacement for a real change-management process.
Trust & references
Cross-checked against the following references.
- Explore the Salesforce Setup MenuSalesforce
- Monitor Setup Changes with Setup Audit TrailSalesforce
Straight from the source - Salesforce's reference material on Settings.
Hands-on resources to go deeper on Settings.
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. What are Settings in Salesforce?
Q2. How do admins navigate to specific settings?
Q3. What do settings cover?
Discussion
Loading discussion…