When using SAML JIT to provision Community Users, who is the CreatedBy user when JIT, upon not finding a match on federationId or contact Email, creates the Contact - Account - User?

Provisioning rules are governed by this sequence

Sequence of actions for JIT provisioning

As documented in this knowledge article, when provisioning over SAML, Salesforce first attempts to match the Federated ID to the Federation ID field of a User record.

If a User record with a matching Federation ID is found, the user is authenticated, and all of the editable User fields specified in the assertion are updated with the values assigned. In addition, some of the Contact and Account fields can be updated (e.g., the Account.TickerSymbol field can be updated; Contact.LastName and Contact.FirstName can be updated).

If no matching User record is found, Salesforce searches all Contacts for a match based on Email. If a matching Contact is found, Salesforce creates the User record and updates the Contact fields specified.

If no matching Contact record is found, Salesforce searches for a matching Account by Account.Name or Account.AccountNumber.

If a matching Account record is found, Salesforce creates a new Contact on that Account with the last name and email address specified and then creates a User record with the specified fields (1).

If no matching Account is found, then Salesforce creates the Account with the specified Name, AccountNumber, and Owner; creates the Contact with the information specified (again, the Contact.Email attribute must be unique across all Contacts on all Accounts); and creates the User record (2).

(1) The Contact.Email attribute value must be unique across all Contact records on all Account records, or provisioning will fail.

(2) The specified Account Owner must have a Role or provisioning will fail.

1 Answer 1


Knowing these values can aid in constructing work flows to alert your Community Management folks. For example:

  • when an Account is created that could potentially be a variant spelling of an existing Account.


enter image description here


  • The createdby user is also Automated Process


  • The createdBy user is the value of Account.Owner included on the SAML assertion (!?!)
  • A side effect of this is that the Profile for the Account.Owner has to be able to insert and update Accounts. You can't use a Read-Only Profile (like I tried) as you'll get this error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY Api Exception: entity type cannot be inserted: Account

     <Attribute Name="User.Username" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="User.Username">
        <AttributeValue>[email protected]</AttributeValue>
     <Attribute Name="User.FirstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="User.FirstName">
     <Attribute Name="User.LastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="User.LastName">
     <Attribute Name="User.Email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="User.Email">
        <AttributeValue>[email protected]</AttributeValue>
     <Attribute Name="User.ProfileID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="User.ProfileID">
     <Attribute Name="Contact.Email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="Contact.Email">
        <AttributeValue>[email protected]</AttributeValue>
     <Attribute Name="Account.AccountNumber" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="Account.AccountNumber">
     <Attribute Name="Account.Name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="Account.Name">
        <AttributeValue>FooBar Industries</AttributeValue>
     <Attribute Name="Account.Owner" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="Account.Owner">

You must log in to answer this question.

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