Release Updates That Change System Access

1. Why This Topic Matters

Salesforce delivers three major releases a year (Spring, Summer, Winter), and many of the changes bundled with those releases are not simply new features – they are Release Updates that alter how security, sharing, authentication and permissions behave. When a release update changes system access, users can suddenly lose the ability to see records, run flows, call Apex, view lookup names, log in without MFA, or reach a Site as a guest user. An Advanced Administrator is expected to anticipate these changes, test them before they are enforced, communicate the impact, and be able to trace and troubleshoot access problems that appear after a release.

In the Advanced Administrator certification, this topic sits inside the Auditing and Monitoring domain. The exam tests whether you know where release updates live, how their lifecycle works, which tools you use to assess and audit them, and how to respond when an enforced update changes who can access what. Understanding this well also protects your real-world org from outages caused by a date on Salesforce's calendar rather than a change you made yourself.

2. What Release Updates Are

Release Updates (the successor to the older Critical Updates and Security Alerts features) are changes Salesforce introduces that improve performance, logic, usability or, most importantly for this topic, security and access control. Salesforce does not switch them on silently. Instead, each update is published in Setup with:

• A description of what changes and why.
• A category (for example Security, Performance, Logic, or Usability).
• A status such as Available, Due Soon, Overdue, Enforced, or Archived.
• An enforcement date (usually the release in which Salesforce will activate it automatically).
• Get Started steps – a checklist of actions to assess impact, test, and apply.
• Often a Test Run toggle that lets you activate the update temporarily, observe behaviour, and roll it back before the enforcement date.

You find them under Setup → Release Updates. The page has tabs for Needs Action, Due Soon, Overdue, Archived, and Completed, so you can monitor what still requires attention.

Release updates that change system access are the subset that affect authentication, authorization, sharing or visibility. Typical examples from recent releases include (names paraphrased, exact wording changes over time):

• Require Multi-Factor Authentication (MFA) for all direct logins and MFA auto-enablement – changes how users authenticate.
• Enable Enhanced Domains – changes URLs for Sites, Experience Cloud and Visualforce, which can break hard-coded links and integrations.
• Secure Guest User Record Access and Reduce Object Permissions for Guest Users – restrict what unauthenticated Site visitors can see and do.
• Require Permission to View Record Names in Lookup Fields – users without Read access on the related object stop seeing the lookup record name.
• Restrict Access to Custom Settings – requires the View All Custom Settings permission or explicit permission set access.
• Enforce the View Roles and Role Hierarchy permission and Enforce View Setup and Configuration for Flow Builder – tighten who can see metadata and setup data.
• Require User Access to Apex Classes Invoked by Flow, Run Flows in User Context via REST API, and Enforce Sharing for Flows – change whether flows run in system context or respect the running user's permissions and sharing.
• Restrict access to @AuraEnabled Apex methods for guest and portal users based on profile/permission set – requires explicit Apex class access.
• Enable Stronger Protection for Users' Personal Information – hides fields such as email and phone on User records from external users.

The pattern to remember: these updates almost always move Salesforce from a permissive default toward a least-privilege default, so after enforcement people have less access unless an admin explicitly grants it.

3. How Release Updates Work – The Lifecycle

Step 1 – Announcement. The update appears in release notes and in Setup → Release Updates, usually one or more releases before enforcement. Salesforce also sends email notifications to admins.

Step 2 – Assessment. The Get Started panel explains which objects, profiles, permission sets, flows, Apex classes or Sites are affected. Many updates include an impact report, a scanner, or links to a Trailhead module.

Step 3 – Test Run (where available). You enable Test Run first in a sandbox (ideally a Full or Partial sandbox refreshed on the preview release). Test Run turns the update on so you can observe failures in flows, reports, pages and integrations. You can disable Test Run at any time before enforcement. Toggling a Test Run or activating an update is recorded in the Setup Audit Trail, which is how you prove when and by whom it was changed.

Step 4 – Remediation. Based on testing, you grant the required object, field, Apex or custom setting permissions through permission sets and permission set groups, adjust sharing rules, update guest user profiles, fix hard-coded URLs, or redesign flows to run in the correct context.

Step 5 – Apply. Once satisfied, you click Enable/Activate in production before the due date so the change lands on your schedule, not Salesforce's.

Step 6 – Enforcement. On the enforcement date Salesforce activates the update automatically in every org where it is not yet applied. The status becomes Enforced, and Test Run can no longer be turned off. Some updates become Archived afterwards.

Step 7 – Monitor after enforcement. Watch Setup Audit Trail, Login History, Apex and Flow error emails, Event Monitoring (if licensed), Debug logs, and user feedback to catch access problems.

4. Related Auditing and Monitoring Tools

Know how release updates relate to the other tools in this domain, because questions often make you choose the correct one:

• Setup Audit Trail – shows the last 180 days (or longer via download) of setup changes, including activation of release updates, permission changes, and profile edits. Use it to answer who enabled this and when?
• Security Health Check – compares session, password and other security settings against a baseline. It does not list release updates, though some updates affect Health Check scores.
• Salesforce Optimizer – evaluates feature usage and configuration quality; it is not where you apply release updates.
• Login History / Identity Verification History – useful after MFA-related updates to confirm users are authenticating correctly.
• Field History Tracking and Field Audit Trail – track record data changes, not setup changes.
• Sandbox preview – sandboxes on the preview instance receive the new release early, letting you test release updates before production.
• Release Notes and Trust site – authoritative sources for the schedule and details of updates.

5. How to Answer Exam Questions on This Topic

Exam questions rarely ask you to recite a specific update by name. Instead they describe a scenario and ask what the administrator should do or what caused the behaviour. Use this reasoning sequence:

a) Spot the trigger. Phrases such as after the latest release, since Monday users can no longer, guest users on the Experience Cloud site stopped seeing records, a release update was enforced, or no admin changed anything point to a release update, not to a misconfigured sharing rule.

b) Identify what kind of access changed. Authentication (MFA, enhanced domains), record/object visibility (guest user updates, lookup names), setup visibility (roles, flow builder), or execution context (flows, Apex). This tells you where the fix goes – permission sets, sharing, guest profile, or flow settings.

c) Pick the proactive, least-privilege answer. Correct answers typically involve reviewing Setup → Release Updates, enabling Test Run in a sandbox, assessing impact, granting only the needed permissions via permission sets, communicating with stakeholders, and activating before the due date. Wrong answers usually involve giving users Modify All Data or View All Data, deactivating the update permanently (impossible once enforced), ignoring it until enforcement, or using the wrong tool (Health Check, Optimizer, Field History) to find release updates.

d) Use the audit tool that matches the question. If the question asks who turned this on, answer Setup Audit Trail. If it asks where to see pending updates and due dates, answer Release Updates in Setup. If it asks how to test before production is affected, answer sandbox plus Test Run.

6. Exam Tips: Answering Questions on Release Updates That Change System Access

• Know the location: Setup → Release Updates (not Critical Updates, not Health Check). The old name may appear as a distractor.
• Know the statuses: Available/Needs Action, Due Soon, Overdue, Enforced, Archived, Completed. Overdue means the date passed but it has not yet been auto-enforced in your org; Enforced means it is on and cannot be reverted.
• Test Run is reversible before enforcement, irreversible after. A question suggesting you can disable an enforced update is a trap.
• Sandbox first, production second. If an answer choice enables an update directly in production without testing, it is almost never correct unless the question states the due date is tomorrow and testing has been done.
• Least privilege wins. When an update removes access, the fix is to grant the precise permission (object Read, Apex class access, View All Custom Settings, etc.) via permission sets or permission set groups – not broad administrative permissions.
• Guest users are a favourite scenario. Expect questions about Experience Cloud or Sites visitors losing access; answers involve reviewing the guest user profile, guest user sharing rules, and the specific guest-user release updates.
• Flows and Apex context. If a flow that used to work for all users now fails for some, suspect an update that makes flows respect user permissions or require Apex class access; fix with permission sets, or set the flow to run in system context only if appropriate.
• MFA and Enhanced Domains are access updates too. Login failures and broken links after a release often trace to these; remediate by registering verification methods, updating bookmarks, integrations and hard-coded URLs.
• Setup Audit Trail is the audit answer. Activating or test-running a release update is logged there; Health Check and Optimizer are not audit logs.
• Communication is part of the correct answer. Options that include notifying users and stakeholders, documenting the change, and scheduling activation on a change calendar reflect best practice.
• Read for timing words. Before enforcement favours Test Run and assessment; after enforcement favours troubleshooting with audit tools and granting permissions.
• Eliminate extremes. Answers that say ignore the update, wait for Salesforce to fix it, contact Salesforce Support to postpone (generally not possible), or give everyone View All Data can be ruled out quickly.

7. Quick Review Summary

Release updates are Salesforce-initiated changes with a published enforcement date. Those that change system access tighten authentication, sharing, visibility or execution context, so users tend to lose access unless admins prepare. The Advanced Administrator's job is to monitor Setup → Release Updates, read the impact, use Test Run in a sandbox, remediate with targeted permissions, apply before the due date, communicate, and rely on Setup Audit Trail and related monitoring tools to audit and troubleshoot. On the exam, map the scenario to the lifecycle stage, choose the least-privilege and test-first option, and select the audit tool that matches what the question is asking you to find.