As part of the Salesforce Service, we provide various authentication approaches to match the specific needs for your application.
As part of the Salesforce service configuration, you can authenticate in a variety of ways:
Basic: The user has to provide a username/password when prompted. If no additional authentication settings are provided and you are running the flow through the Flow default player, then this is the default authentication approach.
OAuth2: If you set up a connected app using our OAuth2 authentication endpoint https://flow.manywho.com/api/run/1/oauth2 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 access of a flow is set to “Anyone can run this flow”, even if the OAuth2 settings are configured, it will not be used as no authentication is required.
As part of the Salesforce Service configuration, you can specify the authentication 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.
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.
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 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’, database updates will fail as the active user is a public user, and does not have the necessary 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.
It’s important to note a couple of important concepts:
- You can change the authentication strategy value being used by the service at runtime. 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.
- 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.
- If a flow is public (Access set to ‘Anyone can run the flow’), 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.