If you’ve read my blog posts on Lightning, you may recall this post about how we initially addressed users who try logging in with Internet Explorer 11. It wasn’t the most elegant solution.

Enter the awesome, fantabulous, Lightning Champion, Melanie Zilles Head! If you haven’t met Melanie yet, you should make it a priority to do so (her contact info is at the bottom of this post)! I’ve known Melanie for almost 4 years now and am lucky to call her friend. She is the Ft. Worth User Group leader and a powerhouse in the Lightning adoption community! After talking with her about out challenges with IE, and during her Lightning implementation she came up with the perfect way to prevent users from logging in using IE while providing them with customizable guidance on what browsers they should be using!

Without further ado, check out this awesome solution:

You rolled out Lightning, you are checking your adoption metrics in the Lightning Usage App, and you are realizing how many users are currently using IE11 (or versions older than that). Understandably, you are not a huge fan. There are 2 significant issues:

1. IE11 is not here to stay. Even if you opt-ed in for the extended support, Internet Explorer support for Lightning is going scheduled to go away (see Help Documentation). But that doesn’t mean that you are “OK” for now – because IE11 is still known to have significant performance issues (Knowledge Article). You worked hard on your Lightning rollout – don’t let IE ruin it for your users
2. IE11 is known to not meet certain performance and security standards (Knowledge Article). That’s a risk you shouldn’t take.

Nana previously shared great ideas on how to “encourage” users to stay away from IE11 (and therefore the Classic UI), but taking away some of the functions they so desperately need. Unfortunately, there a certainly loopholes (ie links/ Ids that can be posted into the URL) that would still allow users to access what they need.

So, if you find yourself needing a more ‘radical’ approach, read on! You will learn how to use a login flow to prevent users from logging in when they use IE.

What are login flows?

Login flows are basically Visual Flows that allow you to either show custom messages to your user, and for our use case, make an assignment that sets the LoginFlow_ForceLogout(type boolean) output attribute to ‘true’, which will prevent the user from logging in.

If you had a chance to take a sneak peak into a Spring ‘19 pre-release org, you may have seen the brand new and shiny Lightning Flow Builder… If not, here’s your first look into the new design and configuration. #SafeHarbor #ForwardLookingStatement

Task to accomplish:

Do not allow user to log in if IE11 (or any IE version) is used to login.

Solution: Use a Login Flow that does the following:

1. Lookup the Login History to determine the browser and login type used in the most recent (aka current login attempt)

1. Use a formula Resource to use the User Id of the user that is trying to login

• Based on the Login Type value, we are checking for non-Browser (non-Standard UI) activity.

**********************************************************

The list of login type values you may want to include here may vary based on your overall setup,

integrations, etc. It’s recommended you check your login history records

(https://workbench.developerforce.com is a great way to do so) for values that you may be expecting based on your users’ login history and make adjustments to this portion of the flow accordingly.

**********************************************************

• We exit the flow if it is not a true Browser Login attempt (nothing happens, and the user can authenticate successfully).

• If the user in fact uses a browser, we will check the it’s an IE browser.

• If the browser is Not IE, we again exit the flow (do nothing) and the user will get logged in successfully.
• If the browser is IE (IE11, or an older version), we are first showing a quick warning by adding a screen element.

• Next, the LoginFlow_ForceLogout output attribute is set to “true” using an assignment.

• So, in the end, the flow will look like this:

• Lastly you need to create the login flow to actually launch the flow above during a user’s login attempt. For more details, check out the Custom Login Flows help documentation.
  • Be sure to not render this login flow in Lightning Experience. If you do, you may get an error message.

A few more comments:

1. As a best practice, you may want to consider NOT assigning a login flow to your system admin profile – don’t lock yourself out! (Create a test user instead and always test this in a sandbox first!)
2. You can expand on this flow to show custom messages or images, etc. If you to, consider using custom settings or custom metadata types to make your flow more dynamic (without actually having to edit the flow itself)
3. ForceLogout redirect behavior: Know issue in redirect inconsistency: Sometimes user may get redirected to www.salesforce.com instead of the login screen
4. In the past I have experienced that a Lightning for Outlook authentication shows up as a ‘true’ IE authentication (hopefully that won’t be an issue going forward). However, if you run into this issue, you may want to add a “IE bypass” option that can be temporarily enabled for a user to allow the authentication and then be disabled again to ensure the user continues to be prevented from using IE.
5. If you can’t wait until the new Flow Builder is available with the Spring 19 release, you can configure the same thing in the current Cloud Flow Designer – you just want get the pretty LIGHTNING view or simplified UI. #LightningNow #LightningChampion #LightningStrikesFlows

Time to celebrate your users being in Lightning at all times!

Feel free to reach out at any time if you have any questions!

Melanie can be found on twitter: @melsfdc
Linked in: Melanie Head
or via the Trailblazer community: Melanie Head