Salesforce SAML SSO: how to connect third-party apps

How Salesforce SAML SSO works

In SAML, one system vouches for the user and the other trusts it. Here Salesforce is the identity provider (IdP). The third-party app is the service provider (SP).

1. Enable Salesforce as the identity provider

• In Setup, open Identity Provider and enable it.
• Choose the certificate Salesforce will sign with. Create one in Certificate and Key Management if you need a new one.
• Download the IdP metadata or the certificate, and send it to the other system, along with the issuer URL.

Note the certificate expiry date now, and put it on the calendar of whoever owns the org.

2. Create the SAML connected app

The other system gives you two values: its Entity ID and its ACS (Assertion Consumer Service) URL. They go into a connected app in Salesforce with SAML enabled.

• Entity ID and ACS URL: exactly as the other system gives them. One wrong character breaks the login.
• Subject Type: Federation ID, so you control the value each user sends.
• Name ID Format: the one the other system expects.
• Signing algorithm: match what the other system supports.
• Custom attributes: anything else the app needs, like an email or a record ID.

Then give access to the connected app through profiles or permission sets, so only the right users can use it.

3. Match users by Federation ID

The Federation ID on the Salesforce user has to match the user ID in the other system. If it does not, the login fails or lands on the wrong account.

• Set the Federation ID on every user who needs access.
• When a name or email changes in Salesforce, update the other system too. A mismatch there breaks the login.
• Write a checklist for adding new staff, so access does not depend on one person.

4. Deep link to the right record

A login that opens the other app on its home page saves a password, but users still have to search. The goal is to land on the same patient or client they were looking at in Salesforce.

• Store the other system's record ID on the Salesforce record.
• Pass that ID as a SAML attribute, or in the target URL the other system accepts.
• Build the "Open in" button from the IdP-initiated login URL of the connected app, plus the record ID.
• Test that it opens the existing record, and not a blank new one.

A branded loading screen while the other system opens tells users it is working, so they do not click twice.

5. Plan for certificates

• When the IdP certificate expires, every SSO login stops. Renew it before the date and send the new one to the other system.
• If one app needs a different certificate from another, Salesforce can use more than one. Set each connected app to the right one.
• After a renewal, test a login for each connected app.

Debugging Salesforce SAML SSO

Want it set up for you? See our Salesforce SSO setup service, or book a free call and we will check which of your systems accept a Salesforce login.