While I am still trying to figure if this is a Salesforce bug or an issue with the documentation itself, or if I am missing something here, thought of getting some opinion here as well, if anyone has experienced this scenario and possible resolutions.

Use Case: Allow JIT provisioning (User Provisioning Type selected as Standard on the SSO settings setup page)/SSO for Community Users using SAML

The SAML assertion for both scenarios (JIT provisioning/SSO) consists of these attributes:

  <saml:Attribute Name="User.FederationIdentifier" />
  <saml:Attribute Name="User.FirstName" />
  <saml:Attribute Name="Account.AccountNumber" />
  <saml:Attribute Name="Account.Name" />
  <saml:Attribute Name="Contact.Email" />
  <saml:Attribute Name="Contact.LastName" />

Scenario 1 (JIT)

  • Account exists in system
  • Contact does not exist in system
  • User does not exist in system

This scenario works fine based on the documentation. A Contact record is created, a User record is created and the User is logged in to the Community. Excerpt below from the documentation.

Salesforce attempts to match the Federation ID in the subject of the SAML assertion (or in an attribute element, depending upon how the SAML Identity Location is defined in the SAML Single Sign-On Settings) to the User.FederationIdentifier field of an existing user record.

If a user with a matching user record isn't found, then Salesforce searches the contacts for a match based on the Contact ID (User.Contact) or email (Contact.Email). Contact.Email and Contact.LastName are both required properties when User.Contact is not specified, but matching is only based on Contact.Email when both properties exist.

If a matching contact record isn't found, then Salesforce searches the accounts for a match based on the Contact.Account or Account.AccountNumber specified in the SAML assertion. Account.AccountNumber and Account.Name are both required properties when Contact.Account is not specified, but matching is only based on Account.AccountNumber when both properties exist. If a matching account record is found, Salesforce inserts a new user record and updates the account records based the attributes provided in the SAML assertion.

Scenario 2 (SSO:Problem)

  • Account exists in system
  • Contact exists in system - the same Contact as created in Scenario 1
  • User exists in system - the same User as created in Scenario 1
  • Contact's email is updated in system
  • User's email is not updated as Contact's updated email as in above step

This is where the problem is! The documentation mentions as below (even though not clearly specifies what is updated, until you refer to the help article, quoted just after this):

If a matching user record is found, Salesforce uses the attributes in the SAML assertion to update the specified fields.

Then from this help article it clarifies what gets updated:

User record exists: Contact fields (eg LastName, Email) and User fields (eg Email, LastName, etc) are updated.

In this scenario, based on the documentation, a User record should have been found based on the Federation ID, and then Contact attributes should have been updated (even though this too does not seem to be the right, because a Contact email update during JIT/SSO is not a right thing to do if it was done for Business specific reasons). However it ends up throwing an error as "INVALID_CONTACT (23)".

It looks like the process is trying to still lookup a match on Contact even if the User would have been found using the Federation Id. My understanding is that as soon as the User was found, it should login, and update any Contact related attributes which is linked to the Community User record. But as said, this does not seem to be the case.

Now, if I remove the Contact related fields from the assertion, this works fine, i.e., the User is able to login successfully.

The issue here is that, we cannot (and don't want to) control the SAML assertion as the purpose here is JIT provisioning and that the assertion will always have a specified SAML attributes to be sent to Salesforce to support JIT.

While there are options to handle this by writing custom JIT handler, but wanted to get some thoughts here, if anyone has encountered this scenario and if had any solution to address this?

  • What are you using as the FederationId for Contact? Is it their email address? I suspect that may be the case which would cause the kind of problem you're describing.
    – crmprogdev
    Commented Jul 28, 2018 at 10:46
  • @crmprogdev It’s not the email id, but a unique id (kind of employee id). Interesting thing here is that it fails only if the contact attributes are present in the assertion. If I remove those, it works fine.
    – Jayant Das
    Commented Jul 28, 2018 at 13:27
  • Exactly! You're making an assertion that the existing user in your org matches the information the idP is sending you. If the email address is one of the fields, I recommend you remove it to see if that solves the problem. Otherwise, you'll want to sync user email changes independently of your JIT handler.
    – crmprogdev
    Commented Jul 28, 2018 at 13:30
  • Actually I am not using a custom handler yet. Was still trying luck to use ootb as available. And for that per documentation, if there’s a match on the Federation Id, it should not proceed further verifying anything else but update the other fields as specified in the assertion. So in this case even if the email was present, it should have updated the contact (still incorrect I feel) rather than failing.
    – Jayant Das
    Commented Jul 28, 2018 at 13:36
  • If what's in your org doesn't match the assertion from the idP for identity, the JIT handler will fail when it comes to the primary assertion. If you read the docs in detail, you'll discover that certain fields are required in addition to the federationId. The latter is the primary external key.
    – crmprogdev
    Commented Jul 28, 2018 at 13:47

1 Answer 1


So, finally I got a response from Salesforce support as below:

After updating the Contact.Email field on salesforce we need to use the updated Contact.Email attribute while login in to the SAML assertion.

This is not documented anywhere but that's what the support mentioned that its working as designed and that every time a Contact's email changes in Salesforce, and if the Contact's email is being passed in the assertion, the updated email needs to be sent along with in the assertion.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .