Skip to content
SteveTechArcSteveTechArc Courses

Checkpoint challenge

Original, hands-on practice. Never modeled on actual exam questions. This closes the chapter Thinking Like an Identity Architect, chapter 1 of Securing Salesforce: Identity and Access.

Scenario

Section titled “Scenario”

You’re joining a project, and on day one somebody asks you, “How do our people log in to Salesforce?” Most people answer with a sentence: “With a username and password, and MFA.” An identity architect answers with a drawing.

So start with the login you know best: your own. You do it every day without thinking about it. This time, watch it, and draw it as a swim lane. If you can draw the login you do every day, you can draw anyone’s.

Requirements

Section titled “Requirements”
  • A Salesforce org you can log in to. Your own work org or a sandbox is best, because that’s the login you know. If you don’t have one, sign up for a free Developer Edition org; chapter 4’s practice uses two of them, so this can be the first.
  • A desktop browser with developer tools. Every major browser has them.
  • Paper, a whiteboard or any drawing tool. The drawing matters, not the tool.

Constraints

Section titled “Constraints”
  • Your own login only. Don’t watch or record anyone else’s.
  • Keep secrets off the drawing. Never write a real password, code or session value on it. Label the arrows with what kind of thing travels: “username + password”, “the code”, “a session”.
  • Draw only what you saw. If you’re not sure what happened in a step, draw it with a question mark. That’s what a real project’s drawing should do too.

Your task

Section titled “Your task”

1. Clear the way. Open a private browser window, so you start with no session. Open the developer tools and choose the Network tab.

2. Log in, and watch. Go to your org’s address and log in as you always do, with your second factor. Don’t rush. Watch the Network tab as you go: you’ll see the redirects, often with a status code of 302, and each new address the browser goes to.

3. List the parties. Who did your browser talk to? Your org’s login page, your org itself, perhaps a company login page if your org uses single sign-on, and your phone, if you used one. Each one is a lane. Write them across the top of the page, with your browser on the left.

4. Draw the rows. For each step, one row: an arrow from the lane that asked to the lane that was asked, labelled with what it carried, and the answer arrow underneath, labelled with what came back. Time runs down the page.

5. Circle the login screen. Which lane showed you the login screen? Circle it. That’s the lane that decides who you are.

6. Look for the arrows that aren’t there. Did any two servers talk directly to each other, without your browser? Did your phone send anything to Salesforce? Mark each answer on the drawing.

Hints

Section titled “Hints”
  • Most logins have four to six rows. If you have twenty, group the redirects: “asks for the page, gets sent to log in” can be one row.
  • The first row is usually the instance sending you away, because you have no session yet.
  • The second factor is a lane of its own if it happened on another device. Ask yourself what the phone did, and whether it talked to Salesforce or only to you.

A model answer

Section titled “A model answer”

Try it yourself before you open it.

Open the model answer

Here’s one common login: a username and password, then a code from an authenticator app on a phone. Yours may be different, and that’s the point of drawing your own.

Your own login, as a swim lane Your own login, as a swim lane, in four lanes: your browser, Salesforce's login server, your phone with a code app, and Salesforce's instance. Step 1: your browser opens your org's My Domain address and the login server answers with the login screen; that lane shows the screen, so it decides who you are. Step 2: you type your username and password, something you know; the login server checks the password and asks for a code. Step 3: your phone shows a code, made on the phone with no call to Salesforce; you read it and type it in, something you have; the login server checks it and answers with a redirect and a session. Step 4: with the session, the instance shows Home. Footnote: no arrow to the phone: a code app makes each code itself, from a secret it was given once, when you registered it. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-06", "id": "DGM-IAM-IM-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} YOUR BROWSER SALESFORCE'S LOGIN SERVER YOUR PHONE: A CODE APP SALESFORCE'S INSTANCE 1. Opens your org its My Domain address The login screen this lane shows it, so this lane decides who you are 2. Types username and password something you know Checks the password then asks for a second factor Shows a code made on the phone; no call to Salesforce 3. Types the code something you have: read off your phone Checks the code then gives the browser a session 4. Into the org with the session Home you're in asks to log in the login screen username + password a code, please the code redirect + session asks, with the session Home No arrow to the phone: a code app makes each code itself, from a secret it was given once, when you registered it. HOW TO READ IT the check passes © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

What to check in your own drawing:

  • The login server’s lane is circled. It showed the login screen, so it decides who you are.
  • There’s no arrow to the phone. A code app makes each code itself, from the time and a secret it was given once, when you registered the app. The code reaches Salesforce only because you read it and type it in. That’s the same lesson as chapter 4: some of the most important trust in identity has no arrow on the diagram, because it was set up in advance.
  • Every call starts at the browser, and every answer goes back to it.
  • Two factors of two different kinds: something you know (the password), and something you have (the phone).

Discussion

Section titled “Discussion”
  • If your org uses single sign-on, the login screen was in a different lane: your company’s identity provider. Where did Salesforce send you, and how did you get back? Chapter 4 draws exactly that.
  • If you approved a notification on your phone instead of typing a code, your phone’s lane has arrows of its own. Draw what you saw, and mark what you’re not sure of. Which lane do you think started that conversation?
  • If you used a security key or your laptop’s fingerprint, there may be no phone at all. Where does that factor sit on your drawing?
  • What would change for a customer logging in to a site, not an employee logging in to the org? Chapter 14 asks it.

Check your drawing

Section titled “Check your drawing”
  • Every party has its own lane, with the browser on the left.
  • Time runs down the page, one row per step.
  • Every call has its answer, each labelled with what it carries.
  • The lane that shows the login screen is circled, and there’s only one.
  • No passwords, codes or session values are written on it.
  • Anything you weren’t sure of is marked with a question mark.

Keep the drawing. When you finish chapter 4, draw it again, and see what you’d change.

Exam objectives exercised

Section titled “Exam objectives exercised”

This practice supports describing common authentication patterns and how they differ (Identity Management Concepts, 17% of the exam), which chapters 2 to 5 teach.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.