Set Up Salesforce With Google Single Sign-On (SSO)

By Paul Ginsberg

One of the more tedious jobs as a Salesforce admin is resetting user’s passwords. Even though there’s a button on the Salesforce login screen which says “Forgot your password”, some people don’t notice it.

If only there was an easier way?

Introducing Single Sign-On

The concept behind Single Sign-On (SSO) is easy: sign in to one system, and then be automatically signed into all the rest of the applications you need. Fewer passwords, fewer headaches, less tedium and it should enable you to get on with what you actually intended to do, rather than get bogged with admin stuff such as hunting around for where you put your password hint*.

*we recommend looking at either Password.docx or the yellow post-it on top of the laptop.

The best implementations of SSO seem to work by magic. The user shouldn’t even notice that it is there, it’s just seamlessly passing your login validation from one system to another without any end user intervention. But that costs a lot of money to set up, right? Not necessarily.

In this guide, I’ll be walking you through a basic out-of-the-box setup, showing that if you use GSuite (i.e. the business edition of Gmail) your users never worry about their Salesforce password again.

It’s worth noting that there are other types of login, such as:

  • With Salesforce, or another system entirely (such as LinkedIn or Facebook), as the lead
  • Where user management is also enabled, allowing an admin to create a user in one system (such as GSuite or Microsoft 365) and it automatically creates the associated account in other systems (such as Salesforce)
  • Password-less systems such as Lightning Login

Check out Martin Humpolec MVP’s blog for more details about each of these. They all have pros and cons: in terms of features, ease of use, user account management and some are more fiddly to set up than others.

Source: Google

Benefits of SSO

For the avoidance of doubt, these are some of the tangible benefits of SSO:

  1. Increased user adoption (seriously, people stop logging in if they find remembering password #87 too difficult)
  2. Reduced admin cost (fewer support requests)
  3. Time savings (5-20 seconds each user, each and every time, and that’s presuming they don’t ever do typos)
  4. Improved security (one policy; not multiple sets to align), and users will be quickly and automatically removed when they leave as long as the lead system is updated
  5. License savings (see above point about automatic decommissioning of access to applications)


  1. You need to be both a GSuite and a Salesforce admin to accomplish this mission, or be on good speaking terms with the relevant administrators.
  2. You should have already enabled and setup “My Domain” on your Salesforce.
  3. The first time you try this, please use a Developer Org or Sandbox. I’ll be using a Developer Org which is why some of the URLs will look a little strange.
  4. For the sake of the example we will be walking through, your organisation’s email addresses must be the same as your Salesforce production org usernames. (e.g. GSuite account is and Salesforce username is also In real life this doesn’t need to be the case as there are easy workarounds.

Strong Recommendations

  1. Most people have more than one Google/GSuite account these days… For your sanity, on your computer, I recommend you use Incognito Mode on your browser; just log into the GSuite account where you are both the Administrator, and wanting to connect that org to Salesforce. Otherwise Google will keep on trying to push you into the Admin Console of your first-listed account, potentially with undesirable consequences 🙈
  2. You know that the first time you do this, you should practice on a Sandbox or Developer Org, right? 😀


Within Google/GSuite Admin Console

Step 1: Go to your GSuite Admin Console and login:

It will look something like this:

Step 2: Go to APPS (the multi coloured square on the screenshot above) and then to “SAML apps“.

Step 3: Click on the “+” in the bottom right hand corner.

Step 4: Use the Filter box that appears to select Salesforce or Salesforce Sandbox (depending on what you are connecting to).

Step 5: On the following screen download IDP metadata by “2nd option” (see pink highlight on screenshot below).

Step 6: Press “Next” and leave where you are as it is, and open up a new tab. You’ll come back to it later.

Within Salesforce

Step 7: Navigate to Setup – Identity – Single Sign on Settings (or, within Setup, type “Single” into either of the search bars)

Step 8: Click “Edit” (highlighted in pink, in the screenshot above), check “SAML Enabled” and click “Save”

Step 9: You’ll then be returned to the previous screen (same screenshot, above).

Step 10: Click “New from Metadata File” and choose the GoogleIDPMetadata XML file you downloaded in Step 5 and then click “Create”.

Step 11: On the next screen (see screenshot below) you will just want to change the “Name” and “API Name” to something meaningful; this will also be displayed to your end users who are logging in. Don’t worry too much though – you can come back and change the Name and API Name later on, without impacting anything else.

Tip: I tend to go for Company Name + GSuite (e.g. “Naturally IQ GSuite” / “Naturally_IQ_GSuite”) as, inevitably, if if I just put “Google” or “Gmail” some people will mistake it for a search engine shortcut or their personal email account.

And then press “Save”… so not much to update on this screen despite all the red text and red lines; you do not need to choose a file for Identity Provider Certificate even though there’s a red line against that item seemingly indicating that it is mandatory.

Tip: This screen is worth exploring for yourself later, as it allows for lots of customisations, whether that’s flexibility around username formats (“Federation ID on the User object”), logout screens (“custom logout URL”) or generating user accounts on the fly (“user provisioning enabled”).

Step 12: This is the screen that you get when you press “Save”. Make a note of the Entity ID (e.g. copy it into Notepad/computer memory) as you’ll need it for Step 14.

Within Google/GSuite Admin Console again

We’re continuing on from Step 6 here, where you’ll be on a screen saying “Step 3 of 4”.

Step 13: Press “Next” to continue to “Step 4 of 4“. You’ll see a screen like this:

Step 14: These are the details you’ll need to fill in:

  • Signed Response: Yes / Tick / True
  • ACS URL: The “Entity ID” from the previous SAML Single Sign-On Settings screen (see Step 12).
  • Entitly ID: The “Entity ID” from the previous SAML Single Sign-On Settings screen (see Step 12).
  • Start URL: The “Entity ID” from the previous SAML Single Sign-On Settings screen (see Step 12).

Yep, all those three entries require the same information.

i.e. e.g.

Make sure your Entity ID field is copied EXACTLY from the Entity ID field in your SAML configuration in Salesforce in Step 12.

And that Entity ID, you may recognise it from somewhere else….

Tip: By default the Google example will have a slash at the end of the Entity ID URL while Salesforce does not use this. You need to use the one that Salesforce gives you. Also, Google says to include your org ID for the ACS (e.g. but I’ve found that is no longer necessary and including it can cause new SSO setups to fail.

Step 15: It will look something similar to the screenshot below (just with your own org’s details):

Step 16: Click “Finish“ and you should see the following confirmation message:

Step 17: Press “OK” and you’ll be taken to Google Admin Console’s SAML Apps’ Settings for Salesforce screen (see screenshot below).

Step 18: Click “Edit Service” (highlighted in pink, on the screenshot above), select “ON for everyone” and then press “Save.”

Step 19: Yes, this change really can take up to 24 hours, even for small organisations. You still need to complete a few more steps (see below), but in the meantime our very own SalesforceBen gave it a try, may not have waited all of the 24 hours, and got the following screen:

When he came back later, having waited the whole 24 hours, it all worked without any problems.

So, grab a coffee and then consider documenting this change that you are making. Especially reference the “Epilogue” section of this guidance as you’ll have to do some annual maintenance.

Back in Salesforce

Step 20: Navigate to Setup – Company Settings – My Domain

Step 21: Click “Edit” by “Authentication Configuration” (highlighted in pink, on screenshot above)

Step 22: Tick the “Name” that you chose earlier (in my example it was “Naturally IQ GSuite”). Consider coming back later and unticking “Login Form” (see tip below), but make sure everything is working first!

Tip: Unticking Login hides the “login” box (asking for Salesforce username and password) from the user’s initial screen and is a wonderful piece of decluttering, but doesn’t actually remove it as an access method; users can still login via customised URLs. To remove the option of users logging in with Salesforce credentials entirely, you need to log a case with Salesforce Support to enable Delegated Authentication. This way Salesforce always logs in via GSuite, so the account has to be active there, before logging in, further improving security.

Step 23: Suggest to the users that they create a bookmark in their web browser with their Salesforce domain.
i.e. e.g.

Step 24: Actually we’re done but do read the Epilogue as annual “maintenance” will be required.

What it looks like in practice

Ellen logs into her Gmail.

Ellen clicks on her specific-instance Salesforce bookmark (e.g.

After a few, short, automatic browser redirects, Ellen gets the following screen:

Tip: If Ellen happened to have more than one GSuite or Gmail account open on her computer, she would have first seen a screen asking her what account to use. It would have looked like this:

Clicking on the correct (work) account would have then taken her into Salesforce.


After a period of time, perhaps one or two years, you’ll receive an email about “SFDC Expiring Certificate Notification” in your inbox.

It is easy to fix!

Step 1: Within Salesforce’s Setup, go to Single Sign-On Settings within Setup, then click on the SAML Single Sign-On Settings you created previously

Step 2: Check the certificate name matches the one you received an email about (otherwise the issue is elsewhere).

Step 3: Go to Certificate and Key Management (within Setup) and click “Create Self-Signed Certificate”

Step 4: You can now create your new self-signed certificate (and give it a better name!); click “Save” at the end.

Step 5: Pop back to the SAML Single Sign-On Settings screen in Step 2, click “Edit” and choose your new certificate.

Step 6: Press “Save” and all done! (well, perhaps give it a test to check that the Single Sign On login is still working 👌).


Huge thanks go to Ben McCarthy, Marie van de Roekel, Mariella Brodersen, Martin Humpoec, Patrick Connelly and Puneet Mehta for their technical guidance, proof reading skills, putting this blog to the test and, most importantly, time!

The Author

Paul Ginsberg

Paul is a nonprofit specialist and Golden Hoodie.


    September 05, 2020 6:51 pm
    Superb tutorial! My question is, how would you link each google account to its salesforce user? I guess the email set in Salesforce must be one from google (Gsuite or Gmail)
    October 14, 2020 4:59 pm
    Yes - it's set for the whole domain (so GSuite is required, not Gmail). There's a workaround using Federation ID on the User object where you can specify individual email addresses for each person, but that's where sandboxes come in handy for testing things :)
    October 21, 2020 2:04 pm
    Hi, I am receiving an error that doesn't leave any logs at Salesforce, even of an attempted login, I can't seem to get at where to look for what's cause the problem. I've followed these instructions exactly, checked my URLs, all seems fine. The error URL is and the error message is Can you point me in a direction to even start digging for more information to solve this? Thank you!
    October 22, 2020 2:30 pm
    It's likely that there is a typo/misunderstanding, so perhaps get a colleague/friend to peer-review for a fresh pair of eyes (that's my #1 tip). There's some more guidance here, but also post on particularly asking for SAML troubleshooting steps. Unfortunately with the information provided it's not enough to be able to assist further (with my skill set!).
    October 26, 2020 9:02 am
    Hi, thanks for this tutorial. Everything's working as intended, however, when I click my org's URL (bookmarked in the example) I am taken to the Salesforce login page where I have to click on the SSO option, which then automatically logs me in. In your example, no SSO button clicking is required. Couldn't know why. Any idea?
    Paul Ginsberg
    October 27, 2020 7:58 pm
    As an educated guess within the "My Domain" screen, edit Authentication Service, and untick Login Form.You are ok, but for everyone else, make sure your login is working correctly with Google SSO first!! If you need to login with a weird/wonderful/non compliant username later you'll need to go to instead.
    October 27, 2020 9:02 pm
    Hi, would you be willing to help me figure out why mine isn't working? I'm receiving an error and followed everything I can see exactly, would you be willing to email me at rob at ? so I can compare what you're seeing with what I am?
    October 28, 2020 11:11 am
    Hi Robert. Unfortunately that's not possible due to other requirements I have on my time. Google SSO is possible, but is fiddly. I think this is the last post I'm going to reply to on the subject (to help manage everyone's expectations) BUT I do recommend you reach out to the Trailblazer Community (in all its guises) as that's what has really helped me overcome any number of technical challenges. There's an amazing bunch of people out there only too ready to help share their experience and knowledge. More details is this great article, just published ;) and look out for another one, next week entitled "Networking in the Salesforce Ecosystem" which gives more hints and tips. p.s. Sorry for not replying to your first message - I thought I had, but the above post covers the same area of advice I would have given.
    Brian Rauch
    November 05, 2020 4:11 pm
    One edit here. These instructions didn't work, and I finally figured out why! The ACS URL is NOT the same as the Entity ID. It is the Login URL from your SAML Single Sign-On Settings page from the step above into the ACS field. This will contain your org Id at the end of the URL This will fix the issue!
    November 09, 2020 5:05 pm
    Glad to have your input and thank you for sharing. It's weird. Glad to have your confirmatio - I thought I had seen this previously but wasn't too sure. This guide was thoroughly tested and has worked for many people but I'm suspecting there's a setting somewhere (no idea where) that makes a difference as to what value is accepted. Perhaps it could be something like type of Google Account or age of Salesforce implementation for all I know(!)
    François Lachausse
    November 12, 2020 9:36 am
    It was getting a 403 app_not_configured_for_user because ACL URL was missing the org id at the end
    Siobhan Venman
    December 04, 2020 10:21 pm
    Does enabling this as described in the article impact integration users? I didn't see any mention of excluding specific "users" from the SSO requirement. Thank you!
    December 07, 2020 11:59 am
    No, as long as you don't play with other settings on that screen, it won't affect integration users. This method (as described - other settings are different!) gives you additional login options, and doesn't take anything away.
    Abhinav Parashar
    January 04, 2021 6:16 am
    Hi there, Thanks for the tutorial. Waiting on the 24 hour window after selecting "ON for everyone" Out of curiosity - would this guide provided by Google be useful as well? Thanks for any comments/thoughts
    January 13, 2021 3:38 pm
    Robert, curious if you ever got this to work, and if so, what the fix was?
    January 13, 2021 4:24 pm
    Just noting that this was the fix for me as well.
    Ryan Diks
    February 09, 2021 4:55 pm
    I must have missed something big, but how does this work when you're being smart and starting in the sandbox? The logins in the sandbox are not the same as production since the sandbox has the .[sandboxname] appended to it. I don't see how the Gsuite email and the sandbox login can match here.
    February 10, 2021 11:16 am
    Two parts: You'll spot a field on the User object which says Federation ID - put the email address there. Within Setup, select SAML Single Sign-On Settings and then SAML Indentity Type: "Assertion contacts the Federation ID on the User object"
    John Sadler
    April 23, 2021 3:43 am
    Does anyone know how this would be affected by Salesforce enforcing MFA early in 2022?
    Stephanie Stoddard
    June 10, 2021 9:23 pm
    John, did you receive an answer to this question, either here or elsewhere? I have the same question and cannot seem to find an answer.
    June 11, 2021 11:19 pm
    John, Stephanie, there is an article that calls this question out that I recently came across when researching the same question: It specifically calls this out: Does SSO satisfy the MFA requirement? Yes — as long as all of your Salesforce products are integrated with SSO, with MFA enabled on the IdP, and all users who access a Salesforce product’s user interface do so via SSO. Note that you must use a federated SSO solution based on the Security Assertion Markup Language (SAML) or OpenID Connect standard protocols. Delegated Authentication does not satisfy the MFA requirement. Hope this helps!
    July 27, 2021 6:56 pm
    HI , Thanks for the tutorial , I have followed all the steps but after all , I am getting Single sign-on error "We can't log you in because of an issue with single sign-on. Contact your Salesforce admin for help." Please assist
    August 18, 2021 8:58 am
    Sorry ... just saw this. Looks like Siobhan has helped us out
    John Sadler
    August 18, 2021 8:59 am
    Thanks Siobhan. Only just saw your post. :-)
    John Sadler
    September 09, 2021 9:12 am
    What would really help is a screenshot of what's in Google and not just what's in Salesforce A screenshot would possibly have picked up on Brian's comment - I think we may have made this mistake Brian Rauch November 5, 2020 at 4:11 pm One edit here. These instructions didn’t work, and I finally figured out why! The ACS URL is NOT the same as the Entity ID. It is the Login URL from your SAML Single Sign-On Settings page from the step above into the ACS field. This will contain your org Id at the end of the URL This will fix the issue!
    John Sadler
    September 10, 2021 12:20 am
    Got the same error Raman ... it's very frustrating. Also frustrating is the initial Salesforce setup where it takes 24 hours before you can even test. Would be nice if some screenshots of Google setup were included and not just the Salesforce side. Did you get it working? We are still stuck.
    Stephanie Stoddard
    October 06, 2021 1:37 pm
    I want to use my SSO configuration for portal users as well. How do I configure SSO in Google to allow for standard Salesforce users and portal users to use the same SAML SSO? When I try to login as a portal user using the Google App, I get this error: "Failed: Invalid Portal ID", and the Login URL is for our production org, rather than the portal URL. I am not sure how to pass the portal ID to Google, and also how to tell Google which users need to use which URL to login.
    December 07, 2021 5:54 pm
    Does having Google Single Sign on impact e-signature capability?
    December 13, 2021 11:29 pm
    Hi Brian, Just wanted to confirm a few things, On the SSO page in salesforce so would the following be correct: Entity Id e.g: And on the Google side: ACS URL e.g: Entity Id e.g: Start URL e.g: Any hep would be appreciated. Thank in advance
    Aaron Heitzer
    January 05, 2022 10:42 pm
    Regarding Epilogue/Maintenance: When the Google certificate expires... The existing ID provider certificate says 'no file chosen' while *editing While *viewing the same setting, it shows the expired Google Workspace cert I can't find a way to add the XML without 'New from meta..' When the Google SAML cert expires, can the new one be added to the existing SSO Settings somehow? Does it become an OpenSSL situation to get the crt that it wants? How to tie the SF self-signed cert, outlined in this (solid) guide, and the Google SAML cert beyond building a new SSO setting? Thank you
    January 10, 2022 4:22 am
    Has anyone configured this recently ? We're getting an error on google and nothing is getting passed it so far. Waiting on a response from google support
    Erin Ryan
    January 11, 2022 1:56 pm
    google SSO w/MFA to access salesforce We are implementing google SSO w/ MFA to access salesforce. I know that salesforce will recognize the google MFA login but I'm unclear if salesforce end users still require the MFA permission set. Thanks for the support.
    January 13, 2022 12:05 am
    Does the Authentication Service Appear on its own after some time or do we need to go and manually create via Setup>Auth. Providers?
    Kingsley Barba
    January 17, 2022 5:10 am
    It works in browser but not in salesforce mobile app(ios and andriod). I also followed the instruction of server switcher article from salesforce but still im getting a singe sign-on error. Does anyone experienced this kind of issue? Kindly suggest what should i do to make it work in mobile.
    Bryan Collins
    January 26, 2022 5:08 pm
    For the section mentioned below, what are the workarounds? "For the sake of the example we will be walking through, your organisation’s email addresses must be the same as your Salesforce production org usernames. (e.g. GSuite account is and Salesforce username is also In real life this doesn’t need to be the case as there are easy workarounds" For the section mentioned above, what are the best workarounds? I am trying to set up Google SSO in Sandbox, but my Sandbox username doesn't match my Google email.
    January 27, 2022 1:50 pm
    Hi paulginsberg We have a SAML app configured for GSuite and Salesforce SSO. We have also configured auto-provisioning, during this configuration we authorized an admin user. Is there a way for us to track some logs when the user is successfully authorized on GSuite or on Salesforce?
    Joshua Carlson
    January 28, 2022 8:31 pm
    I have followed your steps exactly, but when i try to authenticate with Google, it says the following. "Single Sign-On Error" We can't log you in because of an issue with single-sign-on. Contact your Salesforce admin for help.
    Karishma Haji
    January 31, 2022 5:47 pm
    A quick update for all of you using Google SSO. After enabling Google SSO when users were using the “log in via Gsuite” credentials (example scenario: user receives an email with a case id or a slack message with a case id) they were running into a "we can't log you in because of an issue with single sign-on." Upon checking the login history and saw that it showed "“SAML Idp Initiated SSO - Success” even though it actually failed. This is because the ACS URL in google did not include the org ID IMO it should have really said "Service Provider Initiated SSO failed" or something along those lines. Using is fine when it’s going from SSO --> SFDC but when it’s SFDC --> SSO it needs the org ID (e.g.
    Karishma Haji
    January 31, 2022 6:47 pm
    Are you trying to use the 'log in using Gsuite' button or using the Salesforce app in Gmail app launcher?
    February 01, 2022 9:05 am
    Hello Joshua, I got that error and I think it's related to the browser's cache, open the link from an incognito tab to see if it works. Cheers
    February 01, 2022 9:06 am
    Thank you very much for the tutorial Paul, it has served me perfectly
    June 16, 2022 2:53 pm
    Is this tutorial still working? because I've done every steps of the way, but I still have error message: "We can't log you in because of an issue with single sign-on. Contact your Salesforce admin for help." What's the potential issue here?
    Paul Ginsberg
    June 17, 2022 3:00 pm
    Hi. This tutorial is still solild, although some of the page layouts have changed since it was written. You may need to go through the instructions again as that error message indicates a configuration issue.
    July 18, 2022 10:32 pm
    Hi! I followed these steps but when I want to log in using G Suite I can get this message: Error: app_not_configured_for_user Any tips? Thanks!
    August 05, 2022 7:19 pm
    Hi Everybody, This tutorial works just fine, I had a problem with the following error though: "We can’t log you in because of an issue with single sign-on. Contact your Salesforce admin for help.” For all of those having the same issue here is how to solve it (at least what worked in my case). Add your Org ID to the ACS URL in Google, example: I used a chrome extension called SAML Tracer and that's how I noticed that that was the problem. Hope this helps.
    November 29, 2022 1:30 am
    Hey Folks :) Please try changing your "certificate file type". Mine was in "PEM" format & changing it to "CER" worked. I was stuck with the same error for days. Hope this helps :)
    Caroline Ngetich
    January 27, 2023 2:15 pm
    Dear @Stephanie, did you get any help with setting up portal users for SSO? I am facing the same issue
    June 19, 2023 1:57 pm
    Hi , I have performed all the above steps to set up the SSO but not the able to find my SSO option in Authentication Configuration. Please help me with that . How can i check if I have set up SSO correctly or not ?

Leave a Reply