ข้ามไปยังเนื้อหา
SteveTechArcSteveTechArc Courses

Study guide

เนื้อหานี้ยังไม่มีในภาษาของคุณ

Study guide for chapter 2 of the Securing Salesforce: Sharing and Visibility course, a shared chapter that’s also part of the Identity and Access course. Read the five modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guides’ lists of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

Logging in belongs to the Identity and Access Management Architect exam more than to the Sharing and Visibility one. Its exam guide expects candidates to know why MFA matters and how to implement it, and to explain the use of login flows. So each point below names the Identity objectives it supports, and the one Sharing and Visibility objective this chapter touches. Both exam guides predate the 2025–2026 changes at the door: the Sharing and Visibility exam aligns to Winter ‘23, the Identity and Access Management exam to Summer ‘23.

For the Exam

Section titled “For the Exam”

Tick them off as you go. Each one links to where it’s taught.

The doors and the guard (supports IDC-2)

  • I can name the doors into an org (the login page, Experience Cloud sites, public sites, web-to-lead and web-to-case, inbound email, client applications and the APIs) and say which ones need a login. (The doors into the building)
  • I know every door that needs a login goes through the same authentication server, even with single sign-on. (The security guard)
  • I know a token is shown on every request instead of a password, and that while it’s valid, it is the access. (The wristband)
  • I know authentication ends when the user has a valid session and can start making requests; everything after that is authorization. (Where authentication ends)

Proving who you are (supports IDC-2 and AMB-1)

  • I can name the three kinds of proof (something you know, have, are) and say that MFA means at least two different kinds. (Three kinds of proof)
  • I know password policies can be set for the whole org and on a profile, and that a profile’s own policies override the org’s for its users. (Passwords: still the first factor)
  • I know the difference between phishing-resistant MFA (passkeys: built-in authenticators and security keys) and standard MFA (authenticator apps), and why a code can be typed into a fake page. (Not every second factor is equal)
  • I can explain why a text message, phone call or email code isn’t enough: it can be talked out of you, it goes to a phone number, and it can be typed into the wrong page. (Why a text message isn’t enough)
  • I know that with single sign-on, the MFA happens at the identity provider, and Salesforce still needs a signal that it happened. (When the company does the checking: single sign-on)
  • I know a session remembers how strong the proof was (Standard or High Assurance), and that a profile can require High Assurance at login. (How strong was the proof? Session levels)

Where, when and how long (supports AMB-1)

  • I know login IP ranges are set on the profile and deny any login from outside them, with the same generic error as a wrong password. (From where: login IP ranges)
  • I know trusted IP ranges are set for the whole org and don’t block anyone: from inside them, users skip the identity verification challenge. (From where, gently: trusted IP ranges)
  • I know login hours are set on the profile, follow the org’s default time zone when first set, and let a logged-in user view the current page but take no further action when they end. (When: login hours)
  • I know the session timeout can be set for the org and on a profile, and what locking a session to its IP address and enforcing login IP ranges on every request each do. (How long: sessions)

Different users, different doors (supports AMB-1 and AMB-3)

  • I give every integration its own integration user, and know the Salesforce Integration user license and the Minimum Access - API Only Integrations profile. (The integration user that locked itself out)
  • I know a login flow runs after Salesforce authenticates a user, is associated with profiles, works with every way of logging in to the screens, and doesn’t run for API logins. (Login flows: a lobby before the building)
  • I know not to associate a login flow with the administrator profile until it’s proven, and to test it on a dedicated test user with a test profile first. (Login flows: a lobby before the building)

Checking the door (supports OBJ-1, AMB-3 and TPI-5)

What changed in 2025–2026 (newer than both exams’ release alignment, so beyond the exam today)

  • I know MFA is enforced for every employee login, direct and single sign-on, in production from 20 July 2026 by release group, and that admins can’t turn it off. (MFA is no longer optional)
  • I know privileged users (the System Administrator profile, or Modify All Data, View All Data, Customize Application or Author Apex) must use phishing-resistant MFA. (Not every second factor is equal)
  • I know the MFA requirement covers people logging in through the screens, not integrations using the JWT bearer or client credentials flows, which are protected with certificate management and IP restrictions instead. (MFA is no longer optional)
  • I know Salesforce asks users to verify again (step-up) to view and export reports. (Prove it again when the stakes rise: step-up)
  • I know connections from anonymizing VPNs, proxies and high-risk IP addresses are blocked, and that API traffic from them freezes the user. (Where you can’t come from: anonymizing networks)
  • I know idle OAuth refresh tokens expire after 30 days, in production on a rolling basis from 4 November 2026. (The wristband)
  • I know building or editing a login flow needs View All Profiles once profile filtering is on. (Login flows: a lobby before the building)

Beyond the Exam

Section titled “Beyond the Exam”

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

  • Before you secure the front door, count the doors. Every door with no login is a decision.
  • Treat a token like the access it grants. Keep it short-lived, keep it where it belongs, never paste one into an email, a chat or an AI tool, and know how you’d take it back.
  • The more a user can do, the stronger the proof.
  • Every user, and every admin above all, has more than one registered method.
  • Make IP ranges wide enough and narrow enough at the same time, and sometimes that means more than one profile.
  • IP rules are good to a point, but not perfect. No design should depend on them alone.
  • Tell the help desk before you set login IP ranges or login hours: the user gets the same generic error as a wrong password.
  • One integration, one identity. Every rule you relax for an integration user, give back somewhere else.
  • Know how an admin gets back in before you tighten anything at the door.
  • A lobby with a side door isn’t a lobby.
  • A score you understand, against your own policy, beats a perfect number.
  • Know where your integrations really connect from, so none of them freezes its own user.

Words to Know

Section titled “Words to Know”
TermIn one line
Authentication serverThe security guard every login goes through, whatever the door
Session tokenThe wristband a browser shows on every page after logging in
Access token / refresh tokenWhat a client application shows instead of a password, and what lets it get a new one without logging in again
MFAProving who you are with at least two different kinds of proof
Phishing-resistant MFAPasskeys: built-in authenticators and security keys, tied to the real site
Single sign-onLogging in once at the company’s identity provider, which vouches for you to Salesforce
Session security levelHow strong the proof was: Standard, or High Assurance after MFA
Step-up authenticationProving who you are again before a risky action, such as exporting a report
Login IP rangesPer profile: a login from any other address is denied
Trusted IP rangesFor the org: from these addresses, users skip the identity verification challenge
Login hoursPer profile: the hours its users may log in
Session timeoutHow long a session can sit unused before the user must log in again
Integration userA user that a program logs in as, ideally one per integration and API only
Login flowA process users go through after they authenticate and before they reach the org
Health CheckA score and grade for the org’s security settings, against a baseline
Security CenterOne view of security across many orgs, with its own license

Check Yourself

Section titled “Check Yourself”

Short scenarios in the style of the course. Decide your answer before you open it.

1. A company wants its staff to log in without an extra challenge from its offices, and to be asked for more proof anywhere else. Login IP ranges or trusted IP ranges?

Trusted IP ranges, for the org. They don’t block anyone; from outside them, Salesforce challenges the user to verify their identity. Login IP ranges on a profile would deny every login from outside, with no challenge at all. Reread From where, gently: trusted IP ranges.

2. After a profile change, a user with the right password can't log in, and the error looks like a wrong password. What would you check first?

The profile’s login IP ranges and login hours. Both give the same generic error, so the user resets a password that was never the problem. Reread From where: login IP ranges and When: login hours.

3. Two middleware integrations share one integration user. One team deploys with a wrong password. What happens, and what would you change?

The retries lock the user out, and both integrations stop, because it’s the same user. Give each integration its own user, on the Minimum Access - API Only Integrations profile where it fits, locked to the address it connects from. Reread The integration user that locked itself out.

4. A team wants a new login flow live today, on every profile including System Administrator. What do you say?

Not the admin profile until it’s proven: if it fails, you can’t log in to your org. Build and test it on a dedicated test user with a test profile, keep some users off it so the org can always be reached, and leave Render Flow in Lightning Runtime off if the flow enforces security. Reread Login flows: a lobby before the building.

5. An org uses single sign-on, and the company's identity provider sends a text-message code as its second factor. Are its users covered by the MFA requirement?

No. A text-message code is in Salesforce’s “Weak / No MFA” tier, so those users are asked to set up a Salesforce MFA method. Move the identity provider to standard or phishing-resistant MFA, and make sure it sends the signal Salesforce reads. Reread Why a text message isn’t enough and When the company does the checking: single sign-on.

6. You're moving access from profiles to permission sets. Can login hours and the session timeout move too?

No. Session settings, password policies, login hours and login IP ranges stay on the profile; a user has one of each. Many of something goes on a permission set; only one of something stays on the profile. Reread The profile keeps the door; permission sets carry the keys.

7. The weekly Health Check notification says the score dropped. What does that tell you?

That a security setting moved away from the baseline since last week, or that Salesforce added a new check. Find which setting changed, and who changed it, before you fix it. A score that drops on a Tuesday is a door someone opened on a Monday. Reread Health Check: is the door still set well?

Explore

Section titled “Explore”

The official lists of objectives and their weights. Always check the current version before you book an exam.