Open Navigation


Cloud based customer relationship management software


Salesforce is the market leader in customer relationship management (CRM) solutions.


When using the Salesforce connector or Trigger, the first thing you will have to do is click on 'New Authentication' in the step editor:


You will then need to select the 'scopes' for your authentication to configure exactly what access your Tray workflow will have to Salesforce:


Note that for standard use, you will always need to tick the Api scope.

In the next screen you will then be prompted to enter the credentials of the Salesforce user you will be authenticating with. This user must be set up correctly in the Salesforce admin UI, to ensure that you will be able to correctly access all of the available connector operations.

Correct setup of user permissions

The Tray Salesforce connector gives you full access to all of your Salesforce data including leads, contacts, custom objects/fields, and even workflow rules and outbound messages.

Therefore you will need to make sure that the user you authenticate with has access to the correct objects and record types - in a read, write and create capacity, depending on need.

Managing permissions for users in Salesforce can be done using Profiles and Permission Sets.

Note: currently the Salesforce connector can only be used on the Enterprise Edition of Salesforce, and higher. You may use the Salesforce connector on Professional Edition, but ONLY if you've requested API access from your Salesforce account manager. However, you will not be able to use instant WebHooks on the Professional Edition.

Managing access with Profiles

In Salesforce you can allocate a user to a pre-set profile, or you can create your own custom profile.

The available profiles depend on the type of License that a user has.

For example, a Salesforce Platform-licensed user can only have a Standard Platform User profile; while a Salesforce-licensed user ( can have multiple profiles including Contract Manager and System Administrator which gives comprehensive 'super user' access to all functions and objects.

The Contract Manager profile is more suited to the access level that is required by the Tray Salesforce trigger and connector. This can be seen by looking at the 'Standard Object Permissions' section of the Contract Manager profile settings:


You will note that the Standard Platform User does not have the same set of object permissions - for example it has access to Accounts but no access to Leads, Campaigns or Assets:


So a good approach would be to clone the Contract Manager profile and then edit the permissions, bearing in mind the following:

In the Standard Object Permissions section you can set basic read and write access to objects such as contracts, leads and accounts.

In the Administrative Permissions section certain basic key permissions can be set - for example API Enabled must be ticked or the authentication will not work.

Several permissions in the General User Permissions section are relevant in that they allow extra functionality that cannot be granted purely through object-level permissions. For example Activate Contracts must be ticked in order for it to be possible to activate a contract, because the Edit permission on Contracts and Orders is not enough to allow contract activation (you can test activating contracts in Tray with the Update Record operation for the Contract record type - setting the Status field to 'Activated').

This applies to several other options in the General User Permissions section, such as Manage Cases and Activate Orders.

The Salesforce admin UI has tooltips which tell you what object settings are also required for certain permissions:


The following article also provides a useful reference for the object permissions which are required for certain General User Permissions, as well as the required editions:

For example 'Activate Contracts' links to the following page:


This tells you that you need to select Activate Contracts in General User Permissions and set Read and Edit rights on the contracts object in Standard Object Permissions - as already described above.

Managing access with Permission Sets

In Salesforce it is also possible to use 'Permission Sets' to extend users' functional access without changing their profiles.

So you could create a Permission Set which has all the necessary access and then assign it to a particular user to make the necessary adjustments without affecting the profile they are assigned to.

When you create a Permission Set, you can specify the License that it is available for:


Handling Leads in Salesforce lets you handle Leads in Salesforce with ease. Using the Salesforce connector, you can find a list of records from Salesforce, using the "Find Records" operation.

The big gotcha

Leads can be converted. Once a lead is converted, you cannot update them in any way, and they are no longer available in the Salesforce interface.

Behind the scenes in the API, Salesforce uses a "Converted" field which is either true or false. You can use this in the Salesforce connector to get a list of leads who haven't been converted yet, for example.

Going a step further, leads can be converted into Contacts, Opportunities, and Accounts. In tray it's possible to get the "ID" of the relevant new converted objects using the "Converted Account ID", "Converted Opportunity ID" and "Converted Contact ID" fields.

Bulk Operations

The Salesforce connector uses the Bulk API, which follows a slightly different process when manipulating records. When using any operation with the word Bulk in the name, this means that the Bulk API is being used. When a bulk operation is used, Salesforce does not process the data immediately, instead it starts a Bulk Data Load job. The time in which it takes for this job to finish depends on resources available in your Salesforce instance.

The asynchronous nature of bulk data loading in Salesforce means that in the workflow, you would use a bulk data operation and then you would receive a Job ID (or just ID as shown in the connector step output).

This job ID can then be used to poll for the status of the job. Only when the job shows a status of JobComplete has the data been successfully processed in Salesforce.

Bulk upsert example

The following steps are required to bulk upsert records to your salesforce instance. 1. Upload CSV file 2. Create bulk upsert job 3. Poll for job status 4. Deal with job success or job failure

Upload CSV file

The Bulk upsert records operation requires a file object generated by a previous connector step, such as the Google Drive connector, CSV Editor or the Form trigger. This creates a file object that looks like the below.

CSV file object

Create bulk upsert job

The CSV file object can then be used in the Bulk upsert operation. To use the file object, JSON path the whole object from a previous connector step. For more information on JSON pathing, please see this link.

Record type and CSV file input

The External ID field name needs to be specified in External field name. When the data is processed, it is this field that existing records will be referenced by and updated. If Salesforce can't find a record with the same value in this field, it will create a new record. This field must exist in your CSV file.

Additional options are also available for the formatting of the CSV file being uploaded. For example, the default delimiter is a comma but other characters can be chosen. Typically if a CSV file is generated using a Windows application then the Line end would most likely be CRLF, otherwise LF should work.

External field and additional input

Poll for job status

The next step is to poll for the job status. We can do this by creating a loop in the workflow and calling the Get job info operation using the ID field from the Bulk upsert records operation. On each iteration of the loop, we can check if the job has succeeded by looking at the status field. If job has completed it will show a status of UploadComplete.

Polling job status

Deal with job success or failure

After the job has completed, the field numberRecordsFailed can be used. This is found in the output from the Get job info operation.

Job info output

The Salesforce Trigger

Authentication and the Salesforce Trigger

The Salesforce Trigger uses the same authentication method which is described in the first section of this page. Note that when using the Salesforce trigger, you currently must use a permission set and add it to the User that you will be authenticating with. This permission set must have the 'Modify all Data' permission.

Trigger events

The Salesforce trigger has two types of trigger events:

  • Standard trigger events
  • Manually-created trigger events

Standard trigger events

This type of trigger event is where Tray creates a number of Salesforce Objects which results in Salesforce sending notifications when a certain event occurs. These objects are the following:

  1. RemoteSiteSetting: Before any notification can be sent the target URL has to be registered as a RemoteSiteSetting.

  2. Workflow rule: A WorkflowRule is created to tell Salesforce when it should send an Outbound message to the workflow.

  3. Outbound message: An OutboundMessage is created and it defines what data is sent to the workflow.

The operations that fall under this category are:

  • On custom workflow formula
  • On create
  • On create/update
  • On field change
  • On multiple field changes
  • On update

Example: Using the On custom workflow formula

  1. Select the Salesforce trigger when creating a new Workflow.


  1. Either choose a previous authentication or create a new one.

  2. Select the 'On custom workflow formula' operation.


  1. Select which Record type that the trigger will be associated with.

  2. Create a Salesforce workflow formula. This is to let Salesforce know when they need to send a notification to your workflow. For more information about how to create a formula check out the following links:

The formula below tells Salesforce to send a notification when a new Account is created OR when the field Name is updated in an Account.


Manually-created trigger events

This type of trigger event is where you have to login into Salesforce and create/configure a number of Salesforce Objects which results in Salesforce sending notifications to your workflow.

The trigger events that fall under this category are:

  • On Apex Trigger
  • On Outbound Message

Example: Using the On Outbound message event

  1. Select the Salesforce trigger when creating a new Workflow.


  1. Either choose a previous authentication or create a new one.

  2. Select the 'On outbound message' operation.

  3. Select which Record type that the trigger will be associated with.


  1. Make note of the public URL found in the workflow settings. This will be used in later steps.


  1. Login into Salesforce

  2. Click on the Setup button found at the top of the dashboard

docs setup button

  1. Search for RemoteSiteSetting in the search bar and select Administer < Security Controls < Remote Site Settings.

docs new remote site

  1. Click on New Remote Site button and configure new remote site settings where the field Remote site URL is the value of the workflow public URL. When finished hit save.


  1. Navigate to the Search Workflow in the search bar and select Create < Workflows and Approvals < Workflow Rules.


  1. Click on New rule and configure the new workflow rule. This rule is used to tell Salesforce under what circumstances you want Salesforce to send your workflow a notification. workflow-rules

In this case, a workflow will be triggered based on an event associated with the entity Account. object-select The event for when the workflow will be triggered is when a account with a name that start withs the character r is created. workflow-criteria

  1. Create a new outbound message The next stage is to say what happens when the event that was just defined has occurred. In this case we want to create a new outbound message.


This will take you to another config screen where you dictate where and what information you're sending. In the Endpoint URL field, add the public URL that you took note of earlier. You can also then say what information you want sent in the workflow notification. The example below is sending the new Accounts Id and Account Name.


  1. Once complete and saved it will take you back to the workflow rule configuration page. Press the Done button once complete. The last step is to activate this workflow.


White-labelling the trigger

The default behaviour of the trigger is to prefix the newly created objects with the string Tray.


From connector version 2.8 onwards, this prefix can be customised using the Object prefix field found in advanced settings.


The string provided will then be used as the prefix for objects created in Salesforce.


Was this article helpful?