Different Users, Different Doors

Module 4 of 5 in the shared chapter The Front Door: Logging In to Salesforce, chapter 2 of Securing Salesforce: Sharing and Visibility and part of the Identity and Access course. Each module stands on its own.

The question this module answers: Why do staff, admins, integration users and external users need different login policies, and what are login flows for?

Modules 2 and 3 gave you the settings at the door: password policies, MFA, IP ranges, login hours, sessions. Almost all of them live on the profile. That’s not an accident. It means you can set the door differently for different kinds of users, and you should, because the people and programs coming through that door are not alike.

Not every visitor is the same

Think about who actually logs in to an org:

• Staff at a keyboard. They forget passwords, they travel, they work from home. They need MFA, sensible lockouts, and a session that times out when they walk away.
• Admins and other privileged users. They hold the keys to everything, so they need the strongest proof there is, phishing-resistant MFA, and a way back in if something goes wrong.
• Integration users. These aren’t people. They’re programs that log in as a user and call the APIs, sometimes many times a second, all day. A rule that’s sensible for a person can be exactly wrong for them.
• External users. Customers and partners logging in to an Experience Cloud site, with their own licenses and their own rules. Chapter 14 covers them.

One policy for all of them will be wrong for most of them. Let me show you what that looks like.

The integration user that locked itself out

This happened at a client, before Salesforce gave every org its free integration user licenses. There was only one integration user. A middleware platform was using it to bring in updates a couple of times a second, in production, stable, pretty much all day long.

Then a second team released a new component. It shared the same integration user, but they got the password wrong when they went to production. Their component tried three times, and the user was locked out. Not their integration’s user. Both. Because it was the same user.

So I went to reset the password. As soon as I pressed the button, it locked again. I pressed it again, and it locked again. We told the second team to stop, and they did. But the first integration was still coming in, a couple of times a second, with a valid username that was now locked out, and every attempt counted against it. Every time I reset it, the retries locked it straight back.

Click to enlarge

There are three lessons in that story, and they still hold.

One integration, one identity. Salesforce says it directly: “we recommend creating and configuring one Salesforce user for every integration,” because it gives you “more control over operations and traceability of transactions. And it minimizes the impact if a user or integration is compromised” (Give Integration Users API Only Access (opens in a new tab), Salesforce Help, checked 2026-11-01). If each integration had had its own user, the second team’s mistake would have locked only its own.

Click to enlarge

A program needs a different policy from a person. You certainly don’t want an integration user’s password to expire at the wrong time, when no one’s watching. You may want a different lockout rule too. But every rule you relax for an integration user is security you’ve taken away, so give it back somewhere else: lock that user to the IP address its process comes from (module 3), and give it only the access its job needs.

Use the tools made for it. Today, Salesforce gives Enterprise, Performance, Unlimited and Developer Edition orgs the Salesforce Integration user license, with a profile, Minimum Access - API Only Integrations, that restricts the user to API access only. In Salesforce’s words, “You can’t turn off the API-only access granted through this profile.” A user that can’t log in to the screens is one less door. And modern integrations don’t log in with a password at all; they authenticate through an External Client App with OAuth, which the Integration Architect and Identity and Access courses cover.

Admins: the strongest door, and a way back in

For admins, the rules point the other way: stronger, not looser. Module 2 covered the phishing-resistant MFA Salesforce now requires for privileged users. The other half is recovery. Before you tighten anything at the door, know how an admin gets back in if a setting goes wrong, and keep at least one admin who isn’t subject to the change you’re making. That brings us to login flows, where this matters most.

Login flows: a lobby before the building

Sometimes you want something to happen after someone logs in but before they reach the org. I think of it as a lobby: once you let someone in, there are times you want to keep them in the lobby for a moment instead of sending them straight into the building.

That’s a login flow. In Salesforce’s words, “After Salesforce authenticates a user, the login flow directs the user through a process,” and when they finish, they go on to the org; if they don’t, “the flow can log out users immediately.” You build it with Flow Builder or Visualforce and associate it with profiles, and it runs every time a user with that profile logs in, including from the Salesforce mobile app and client apps that use OAuth. It works with every way of logging in, from a username and password to single sign-on, and you can attach different flows to different profiles. It doesn’t run for API logins, or when a session is handed to the screens from a login that didn’t go through them (Custom Login Flows (opens in a new tab), Salesforce Help, checked 2026-11-01), so it’s a door for people, not for integrations.

A login flow also knows something about the login itself. Salesforce passes it details such as the user, the IP address, the browser, the platform, the application and the session level, and the flow can decide where to send the user when they finish, or log them out on the spot (Login Flow Examples (opens in a new tab), Salesforce Help, checked 2026-11-01). That’s what makes it a lobby with a real receptionist, not just a sign on the wall.

Here’s what I use them for:

• Maintenance with a clean message. If you need to keep everyone out for a few hours, you could freeze their accounts, but then they just get a bare login error. A login flow can hold them in the lobby with a clear message: the system is down, we’ll be back in three hours. And it can let your smoke-test users straight through, by a flag on their user record, so they can check the release.
• Terms and conditions. Some companies want employees to accept the terms every month. The login flow checks when they last accepted, and shows the new version if there is one.
• A change you need people to make. A student in one of my classes told me how their company used a login flow to move everyone off an old browser: first a warning that the old one was going away, then, months later, a hard stop with a clear message. It worked.

Click to enlarge

Two warnings, and both are Salesforce’s own. First: “Don’t associate a login flow with your administrator profile until you’re sure that the login flow works properly. Otherwise, if it fails, you can’t log in to your org.” I’d go further: make sure there are always users who aren’t on the login flow and can get into the system if you get locked out. Second, if the flow is there to enforce security, don’t turn on Render Flow in Lightning Runtime: with it on, “users using the login flow have access to Salesforce functionality before they complete the flow” (Set Up a Login Flow and Connect to Profiles (opens in a new tab), Salesforce Help, checked 2026-11-01). A lobby with a side door isn’t a lobby.

Two more practical points. Salesforce’s own best practice is to build and test a login flow on “a dedicated test user with a test profile” before it goes near real users (Login Flow Examples (opens in a new tab)). And since profile filtering is now on by default (chapter 1, module 4), not every admin can build one: “When you enable Profile Filtering, users can’t create or edit login flows. To give users access to login flows, enable the View All Profiles permission” (Limit Profile Details to Required Users (opens in a new tab), Salesforce Help, checked 2026-11-01). Decide who that is on purpose.

Salesforce’s Well-Architected guidance puts login flows where this chapter does: at the identity layer, beside session settings and MFA, one of several independent controls, each designed “as if the layers above and below might fail” (Well-Architected: Trust (opens in a new tab), checked 2026-11-01). A login flow adds a step at the door. It doesn’t replace any of the others.

What an architect decides here

• Which kinds of users the org has, and which profile each kind gets, so each has its own password, session, IP and MFA rules.
• That every integration has its own integration user, on the API-only profile where it fits, locked to where it connects from.
• How admins get back in if a door setting goes wrong, before anything is tightened.
• Which profiles need a login flow, what it does, and who stays off it so the org can always be reached.
• Who may build and change login flows, now that it takes the View All Profiles permission, and which test user and profile they test on first.

Beyond the exam: what AI changes. The programs coming through the door now include agents and AI tools, and the lesson of the integration user applies to them too: each one should log in as its own identity, with only the access its job needs, so one mistake or one compromise stays small. Part 3 of this course and the Identity and Access course go further.

Explore

• Give Integration Users API Only Access (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Custom Login Flows (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Login Flow Examples (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Limit Profile Details to Required Users (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Salesforce Well-Architected: Trust (opens in a new tab), Salesforce Architects (checked 2026-11-01)
• Set Up a Login Flow and Connect to Profiles (opens in a new tab), Salesforce Help (checked 2026-11-01)