The SP-Initiated Flow, Step by Step
Module 1 of 7 in the chapter Salesforce as the Service Provider: SAML, chapter 6 of Securing Salesforce: Identity and Access. Each module stands on its own.
The question this module answers: When Priya opens a Salesforce link first thing in the morning, what does Salesforce do at each step, and what tells it how?
Where we left the swim lane
Section titled “Where we left the swim lane”In chapter 4, you watched Priya’s browser carry every message of a single sign-on login: the redirects, the SAML request, the SAML response, the session. We drew it as a swim lane, one lane for each actor, and saw that the identity provider and Salesforce never call each other. The browser is the broker.
That’s the whole flow, from the outside. Now sit inside Salesforce. This is Part 2 of the course, and the question changes from “what is single sign-on?” to “how does Salesforce do its half?” Most companies sign their staff in to Salesforce from an identity provider they already run. Salesforce is the service provider: the system that trusts someone else to say who she is.
This module walks the most common flow, the one that starts at Salesforce. It’s called service provider-initiated, or SP-initiated, because the service provider sends the first SAML message.
Five steps, five decisions
Section titled “Five steps, five decisions”Here’s the same swim lane, the same cells as chapter 4. What’s new is in the two cards in Salesforce’s login server lane: the settings Salesforce reads.
Let’s take each step from Salesforce’s point of view.
1. A link, and no session
Section titled “1. A link, and no session”It’s the beginning of the day. Priya clicks a link to a Salesforce record: a bookmark, a link in an email, an address her browser fills in for her. The record lives on Salesforce’s instance, the server that holds the org’s data. The instance looks for a session and finds none. So it redirects her browser to the login server.
Remember what a redirect is. It isn’t the instance calling the login server. It’s a command in the page that comes back to the browser, telling it to go somewhere else. The browser does the going.
2. Which identity provider?
Section titled “2. Which identity provider?”Now the login server has to decide where to send her. Salesforce knows because you told it, in a SAML single sign-on setting (Setup, Single Sign-On Settings). That setting names the identity provider and holds everything Salesforce needs to talk to it. Module 3 sets one up.
How does she get to it? Two common ways:
- A button on the My Domain login page. You add the identity provider to the page in My Domain’s Authentication Configuration. The button shows the setting’s name, so Salesforce suggests naming the setting after the identity provider (S1, S7).
- Straight there. Some setups send her on to the identity provider without a click, when it’s the only way in on the login page. How yours behaves depends on the login page’s settings in My Domain, so try it in your own org. When there’s more than one way in, she chooses (Microsoft’s Entra tutorial says the same, S8).
Either way, Salesforce writes a SAML request: please go log this person in. If you chose to sign requests, it signs this one with the Request Signing Certificate from the setting. It sends the request to the address in the Identity Provider Login URL, as a form (HTTP POST) or in the address itself (HTTP Redirect), whichever the identity provider asks for (S1). And the browser goes.
3. The identity provider’s turn
Section titled “3. The identity provider’s turn”The identity provider shows its login screen. It could be a password and MFA, a passkey, whatever that company has set up. That’s the identity provider’s job, not Salesforce’s. When Priya has proved who she is, the identity provider writes the SAML response, signs it, and sends her browser back to Salesforce with it.
4. The checks
Section titled “4. The checks”The browser posts the response to Salesforce’s address for answers. That’s where Salesforce does its real work. It checks the response against the same setting:
- the signature, against the Identity Provider Certificate you uploaded;
- the issuer, against the Issuer;
- the audience, against the Entity ID;
- the time window, and that it hasn’t seen this assertion before;
- and who to log in as, using the SAML Identity Type: her username, her Federation ID or her user ID (module 5).
These are the five questions from chapter 4, module 6, each answered by one field of the setting. One “no”, and she doesn’t get in.
5. The session
Section titled “5. The session”Every answer is yes. Salesforce issues a session, Priya’s wristband from the front door, and redirects the browser back to the record she asked for. The instance sees the session and shows her the record. From the user’s point of view, she clicked a link, saw a login screen, and landed where she meant to go. Everything in between was redirects.
That’s what I mean when I say identity providers don’t get you into Salesforce. They get you into Salesforce’s login server. Salesforce makes the last decision, every time.
One more check since 2026
Section titled “One more check since 2026”Since February 2026, Salesforce can stop an SP-initiated login at step 4 for one more reason. If Priya is on a device or browser Salesforce doesn’t recognize, Salesforce asks her to activate it, unless the identity provider’s response proves she used a secure method such as MFA, or the org’s trusted IP ranges are narrow (S9). So what the identity provider says about how she signed in now matters. Module 4 shows where it says it, and module 7 what to do when the prompt appears.
On the map
Section titled “On the map”On the grid of every way to sign in (chapter 5, module 6), this chapter is the single sign-on set. This module is its first card, SAML started at Salesforce.
Watch it on video
Section titled “Watch it on video”In 2023 I made a short video on this flow, and on what each side sets up. The note under the video says what’s still right and what’s changed since.
What’s next
Section titled “What’s next”Module 2: what happens at the second app of the day, and when the day starts at the identity provider instead.
What an architect decides here
Section titled “What an architect decides here”- Which identity provider Salesforce uses for staff, and its single sign-on setting.
- How users reach it: a button on the My Domain login page, or straight to the identity provider.
- Whether Salesforce signs its requests, and with which certificate.
- Which binding the identity provider expects, POST or Redirect.
Explore
Section titled “Explore”- SAML Single Sign-On Flows (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Step 2: Create a SAML Single Sign-On Setting in Salesforce (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)