Authenticating users with Salesforce

Content under development

As part of the Salesforce Service, we provide various authentication approaches to match the specific needs for your application.

  1. How app users authenticate with Salesforce
  2. How calls to the Salesforce API authenticate
  3. How asynchronous calls authenticate
How app users authenticate with Salesforce

As part of the Salesforce Service configuration, you can authenticate in a variety of ways:

  • Basic: The user has to provide their username/password when prompted. If no additional authentication settings are provided and you are running the Flow through our standard player (“default”), then this is the default authentication approach.
  • OAuth2: If you set up a Connected App using our OAuth2 authentication endpoint ( and you specify the configuration values for Consumer Key and Consumer Secret (as provided in Salesforce), the Flow will automatically use OAuth2 for authentication. This is particularly helpful when running a Flow outside of Salesforce, on a mobile device, etc.
  • Session: If you run a Flow using our template Apex/Visualforce code, we provide the Salesforce session information directly without requiring the user to login or go through the OAuth2 sequence.

The important thing to note is that the authentication of the user is specified by the flow and/or the swimlane. For example, if the flow is set to “Public to the internet”, even if the OAuth2 settings are configured, they will not be used as no authentication is required.

How calls to the Salesforce API authenticate

As part of the Salesforce Service configuration, you can specify the “strategy” under which APIs calls should be authenticated. There are currently three supported authentication strategies:

ActiveUser: The session associated with the user running the Flow is used for all Salesforce API calls. As a result, if the user does not have access to a particular field, record or feature, neither does the running Flow. If this setting is used, the Salesforce Username/Password configuration values are not used. However, if the Flow has swimlanes that reference the User, these swimlanes will error if the user running the Flow does not have access to the User object in Salesforce. A user only has access to the User object if they have “Manage Users” enabled on their profile.
Standard: The session associated with the user running the Flow is used for almost all Salesforce API calls. This is nearly identical to the ActiveUser setting, however, we use the Salesforce Username/Password configuration values for operations that we think the running user will not have access to perform. Primarily, this is for User table lookups as running users do not often have “Manage Users” enabled in their profile.
SuperUser: The credentials provided in the Salesforce Username/Password configuration values are used for all Salesforce API calls. This means the running user can do anything the credentials provided in the configuration can do. It also means that all data inserted/edited is done so under the credentials of the provided user. If ownership needs to be assigned for the running user, it needs to be manually added by an operation, setting the Salesforce Object / Owner Id field to the $User / User Id property in the $User system Value.

Depending on the use-case each of these strategies can play an important role.
Asynchronous Calls
As part of an executing Flow, it is sometimes necessary to provide asynchronous calls to third party applications. For example, we have a Service for a Timer, that waits for a duration of time before continuing the Flow. There are other Services for Box. When making an asynchronous call, identity works slightly differently.

The call to the Service is done under the authentication session information of the Service. For Salesforce, this would include your Salesforce session token. If calling the Box Service, and the user is only logged into Salesforce, the Box Service would show the user as unauthenticated.
When the Service receives the call-out, it is also provided with a unique token that allows the Service to “call back” despite not necessarily being able to authenticate to the Flow normally. I.e. Your Flow may be configured to only be accessible to Salesforce users. However, the Timer Service (despite not having a Salesforce user account), can call back to the Flow as the platform allows the Service to callback because it has a valid token for the call out that was made to the Service.
When the Service calls back with the authentication token, it does so as a “public user”. This means that the Flow has no authentication information for any subsequent calls. For example, with Salesforce, if you have the authentication strategy set to “ActiveUser” or “Standard”, any database updates will fail as the active user is a public user with no credentials to make updates to Salesforce.

As a consideration, if you are doing asynchronous calls to third party applications, you should run the Flow using the authentication strategy of “SuperUser” to be sure the API calls to Salesforce succeed.

One more thing

It’s important to note a couple of important concepts:

  1. You can change the authentication strategy Value being used by the Service at runtime. Meaning, if you create an operator that changes the strategy from “Standard” to “SuperUser”, the configuration settings will be dynamically switched at that point in the Flow. This allows Flow builders much finer grained control of authentication with Salesforce.
  2. Values used in the Salesforce Service configuration should be set to “Do not version this Value”. This ensures that if you accidentally, or purposefully, reset and configuration information on Salesforce, you can update all running workflows with the changed Values. If the Values are not set as “versionless”, they are locked for that Version of the Flow.
  3. If a Flow is “Public to the internet”, you can use Swimlanes to create authenticated sections of the Flow. This can be particularly powerful for “partner” or “customer” use-cases where the customer may get involved in the Flow through parts of the user journey.

Check out the glossary for a definition of terms and key concepts that appear in the Boomi Flow website, Drawing Tool, technical documentation, blogs, and marketing communications.

If you need to take a closer look, click on the images to enlarge them. Have a question? Click the Help button on the bottom right-hand corner of this page to ask.