Login Flows
A Login Flow is a Salesforce feature that runs a screen flow or Visualforce page during the login process, after Salesforce authenticates the user but before the user reaches the org or Experience Cloud site.
Definition
A Login Flow is a Salesforce feature that runs a screen flow or Visualforce page during the login process, after Salesforce authenticates the user but before the user reaches the org or Experience Cloud site. The flow runs in the user's context and can collect or update data, request that the user accept terms, enforce stronger authentication, or apply a custom access policy. Each Login Flow record ties a flow to a User License and a Profile, so every login for that profile runs the flow.
Login Flows work with standard username and password login, delegated authentication, SAML single sign-on, and SSO through a third-party authentication provider. They do not run for API logins or sessions passed through frontdoor.jsp, and they cannot redirect the user to a URL outside the org. The feature is still current and supported, though some scenarios it once handled, such as MFA enrollment, are now covered by built-in identity features.
How a Login Flow controls the login process
Where the flow sits in the login sequence
A Login Flow fires after authentication succeeds but before the user lands anywhere useful. The user has entered valid credentials, or SSO has returned a verified assertion, and Salesforce has confirmed who they are. At that moment the platform hands control to the flow. The user sees the flow screens instead of their home page or Experience Cloud site, and they cannot bypass it. Access stays restricted until the flow finishes. This placement is what makes the feature useful and also what makes it risky. Because the flow runs on the path to the org, anything it shows is mandatory. A terms-of-service screen here cannot be skipped. A second authentication factor here cannot be dodged. The flip side is that a broken flow blocks the path entirely. If the flow throws a runtime error, affected users see an error and stop at that screen rather than reaching the org. That is why Salesforce documentation warns against attaching a flow to your administrator profile until you have confirmed it works.
Flow Builder or Visualforce
Salesforce supports two ways to build the flow behind a Login Flow. The point-and-click option is a screen flow built in Flow Builder. You assemble Screen, Decision, Get Records, and Update Records elements the same way you would in any screen flow, then save and activate it. Activation matters, because you cannot connect an inactive flow to a profile. The screen flow path covers most admin needs without code. The second option is a Visualforce page with an Apex controller. This gives complete control over layout and logic, which suits highly customized login walls or integrations that a screen flow cannot express. The trade-off is that the associated profile must have access to that Visualforce page, and you take on the maintenance of custom code. Most orgs start with Flow Builder and only reach for Visualforce when the screen flow elements genuinely cannot do the job. Both build types are designated as a Login Flow and attached to profiles through the same Setup screen.
Context variables the login event passes in
When the login event triggers the flow, Salesforce passes a set of input variables that describe the session. The flow can read these to make decisions. LoginFlow_UserId carries the Id of the user logging in, which lets the flow query and update that User record. LoginFlow_LoginType and LoginFlow_LoginSubType describe how the login happened. LoginFlow_IpAddress, LoginFlow_UserAgent, LoginFlow_Platform, and LoginFlow_Application describe where the request came from. LoginFlow_Community and LoginFlow_SessionLevel round out the picture. The flow can also set output variables that change what happens next. LoginFlow_FinishLocation controls where the user goes after the flow completes, though it cannot point outside the org. LoginFlow_ForceLogout, when set to true, logs the user out immediately, which is how a flow can deny access to someone who fails a check. Reading the inputs and setting the outputs is how a Login Flow turns the login event into a real decision rather than a fixed screen.
Assignment by User License and Profile
You connect a flow to users through a Login Flow record under Setup. Each record names the flow, picks a User License, and picks a Profile within that license. The flow then runs for every login by users on that profile, across web, mobile, and OAuth client apps. A profile can have one login flow at a time, so you plan which population needs which experience before you start clicking. This per-profile model lets different audiences get different treatment. Internal employees might run no flow at all, while a Customer Community profile runs a consent screen, and a partner profile runs an MFA registration step. Because the assignment is tied to the profile rather than the individual, moving a user between profiles changes which flow they see. Keep that in mind during user administration, because a profile change can quietly add or remove a mandatory login screen for someone.
What people actually build with it
The Salesforce documentation ships example flows that map to the common patterns. Collecting and updating user data is one: the flow asks the user to confirm a phone number or email and writes the answer back to the User record. Accept Terms of Service is another: display the terms, require a checkbox, and stamp a field so you have a record of consent. A welcome or data-collection screen at first login fits the same shape. Stronger authentication is the other big category. The examples include time-based one-time password registration with a QR code, conditional MFA based on whether the IP is trusted, and integrations with hardware keys like YubiKey or SMS services such as Twilio and TeleSign. A flow can also limit concurrent sessions or enforce a custom access policy, for example blocking a community user who has no active support plan. The common thread is a one-time-per-login interaction that has to happen before the user gets in.
Limits, bypasses, and runtime behavior
Several constraints shape how you design a Login Flow. It cannot redirect the user to a URL outside the org, which is a deliberate security boundary. It does not run for API logins or for sessions created through frontdoor.jsp, so automation and certain integration paths skip it entirely. Administrators who use "Log in as another user" bypass the flow as well, which is convenient for support but means you cannot rely on the flow as an absolute gate for those sessions. Runtime mode is worth checking. The documentation notes that when the flow renders in Lightning runtime, users can reach some Salesforce functionality before they finish the flow, which weakens the mandatory nature of the screen. If the flow must be a hard wall, account for that. And because the flow runs on every login for the profile, latency adds up. Keep the flow short, branch early to skip work for repeat users, and push heavy callouts to asynchronous processing so the login does not stall.
When a Login Flow is the wrong tool
Login Flows predate several newer platform features, and some jobs they used to handle now have cleaner homes. MFA enrollment is the clearest case. Salesforce now enforces multi-factor authentication and Identity Verification at the platform level, so building your own MFA prompt inside a Login Flow is usually redundant work. For contextual nudges and acknowledgments, In-App Guidance fires where the user already is, rather than gating every single login. The test is whether the interaction truly must happen before the user reaches the org. Regulatory consent that legal requires at sign-in, a custom branded login wall, or org-specific data you must capture on first entry are fair reasons to use a Login Flow. A tip you would like the user to see, or a setting they can change later, does not justify adding latency and a single point of failure to every login. Reach for the lighter mechanism first, and use a Login Flow when nothing else can enforce the requirement.
How to set up a Login Flow
Build a screen flow, designate it as a login flow, and connect it to a profile so it runs at login. Test in a sandbox before you touch any production profile, and never attach an untested flow to your own admin profile.
- Build and activate the screen flow
In Flow Builder, create a screen flow with the screens and logic you want at login. Read LoginFlow_UserId to identify the user, and use Get Records or Update Records to read and write the User record. Set LoginFlow_FinishLocation or LoginFlow_ForceLogout if you need to control the outcome. Save and activate the flow.
- Open Login Flows in Setup
From Setup, type Login in the Quick Find box and select Login Flows. This page lists existing login flow connections and lets you create new ones.
- Create the login flow connection
Click New. Enter a Name for the definition, choose the type (Flow for a Flow Builder flow, or Visualforce Page), and select your activated flow from the dropdown.
- Connect it to a license and profile
Select the User License that matches your target profile, then select the Profile. The flow now runs for every login by users on that profile across web, mobile, and OAuth apps. Save the record.
- Test before going wide
Test with a non-admin test user on the target profile in a sandbox. Confirm the flow runs, completes, and lands the user correctly before connecting it to broader profiles or production.
Flow for a Flow Builder screen flow, or Visualforce Page for a custom page with an Apex controller. Most orgs use Flow.
The license tied to your target profile. You pick the license first, which filters the available profiles.
The profile whose users run the flow. One login flow can be connected per profile at a time.
Optional output variable that sets where the user lands after the flow. It cannot point to a URL outside the org.
Optional output variable that logs the user out immediately when set to true, used to deny access on a failed check.
- A broken flow blocks login for everyone on that profile. Do not attach an untested flow to your administrator profile.
- The flow does not run for API logins or sessions passed through frontdoor.jsp, and admins using Log in as another user bypass it.
- In Lightning runtime, users may reach some Salesforce functionality before finishing the flow, so it is not always a hard wall.
- The flow runs on every login for the profile. Branch early to skip work for repeat users and avoid adding login latency.
Prefer this walkthrough as its own page? How to Login Flows in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Custom Login FlowsSalesforce
- Set Up a Login Flow and Connect to ProfilesSalesforce
Straight from the source - Salesforce's reference material on Login Flows.
- Create a Login Flow with Flow BuilderSalesforce
- Login Flow ExamplesSalesforce
Hands-on resources to go deeper on Login Flows.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. At what point in the user journey does a Login Flow run?
Q2. How is a Login Flow targeted to a particular set of users?
Q3. Which Flow element completes the login process at the end of a Login Flow?
Discussion
Loading discussion…