2.4 Setup Navigation, Release Readiness, and Change Control

Setup is an operating console

Setup is not a single menu to memorize from top to bottom. It is the operating console for configuration, security, metadata, identity, release readiness, and many admin diagnostics. Setup search helps locate pages quickly, but strong admins also know the major neighborhoods: Company Settings for org defaults, Users for user records, Security for authentication and session controls, Object Manager for object and field configuration, App Manager for Lightning apps and connected apps, and Flow for automation.

The exam often describes a symptom and expects the admin to choose the right Setup path. If the issue is object fields, record types, page layouts, compact layouts, or buttons, start in Object Manager. If the issue is app visibility, navigation items, utility bars, or app branding, start in App Manager. If the issue is login, password, sessions, or network trust, start in Security and Users. If the issue is org identity, fiscal year, business hours, or language defaults, start in Company Settings.

Setup navigation guide

Release readiness is part of admin work because Salesforce is a multi-release platform. Admins should read release notes for features used by the org, review release updates, test in sandboxes or preview environments when available, and understand when changes become enforced. A release note is not a task list by itself. The admin must translate it into org impact: which profiles, apps, automations, reports, integrations, mobile users, and support processes could be affected.

Release Updates deserve special care because they can change platform behavior. Some updates can be enabled, tested, postponed within allowed windows, or enforced by Salesforce at a later date. The admin should not wait until the last day. Review the update description, identify affected metadata or users, test in a sandbox, fix dependencies, document decisions, and communicate timing. If an update affects security or automation, involve the owner of that process.

Change control means knowing the difference between metadata and data. Metadata is configuration such as custom objects, fields, page layouts, Lightning pages, flows, permission sets, profiles, apps, and validation rules. Data is business records such as accounts, contacts, cases, opportunities, products, and custom object records. A deployment tool may move metadata, but it does not automatically migrate production data records unless specifically designed to do so. This distinction prevents many failed deployments and user surprises.

For many admins, change sets are still a familiar deployment tool, especially between related Salesforce environments. Other teams may use DevOps Center, source control, Salesforce CLI, managed packages, or third-party release tools. The exam focus is usually not command syntax. It is the judgment that configuration should be built and tested outside production when risk is meaningful, dependencies should be included, validation should be planned, and users should know what is changing.

Setup Audit Trail is useful after a change, but it is not a substitute for change management. It can show many Setup changes and who made them, which helps investigate incidents and coordinate among admins. However, a mature process also uses requests, approvals, release notes, test evidence, and deployment records. In a shared admin team, two people editing the same automation or page in production without coordination is a preventable risk.

Hands-on practice should include a small end-to-end change. In a Developer Edition org, create a custom field on a test object, add it to a page layout or Lightning record page, assign field-level security appropriately, and document the Setup locations touched. Then imagine deploying it: what metadata must move, who must test it, which reports or automations might use it, and how would you confirm success after deployment? This turns Setup navigation into operational thinking.

Controlled change checklist

• Define the business problem, success criteria, affected users, and owner.
• Identify whether the change is metadata, data, security policy, release update, or a mix.
• Build and test outside production when the change affects shared behavior or critical work.
• Include dependencies such as fields, record types, flows, permission sets, apps, and Lightning pages.
• Validate with representative users and realistic records.
• Schedule the change, communicate impact, and monitor after deployment.
• Use Setup Audit Trail and deployment records for traceability.

Scenario traps are predictable. Do not edit production because one executive is waiting unless the risk is truly low and authorized. Do not deploy a field without field-level security and page placement. Do not enable a release update without testing affected automation. Do not assume a sandbox contains current data or current permissions. Do not assume a successful deployment means users can use the feature; app access, profiles, permission sets, and page activation may still be required.