Notes on using Salesforce
Handling Leads in SalesforceCopy
You can find a list of records from Salesforce, using the "Find Records" operation.
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.
Data processingCopy
When using Salesforce in production workflows, you will likely be dealing with large amounts of data - processing hundreds or thousands of rows.
In this case, you will likely need to make use of callable workflows to send data for sub-processing. Learn more about this in our course on callable workflows from the Tray Academy.
You also may need to use our CSV Editor as an intermediate storage medium, before making use of the batch/bulk operations.
When dealing with large amounts of data in Salesforce it is important to be aware of:
What are the API limits according to your account, in terms of how many API calls can be made per day. Please the Salesforce API limits page for guidance on this
How can you use Tray.io to manage the amount of API calls that are being made?
In order to address the second point, you will see that certain operations for pulling data from Salesforce offer pagination options which allow you to grab batches of data in one and then loop through them with Tray.io, instead of making repeated single calls. The section below on Pulling data and pagination takes you through this in detail.
When pushing data to Salesforce you may need to make use of the batch create / update and bulk upsert operations. These allow you to reduce hundreds of record updates to a single call, and so are extremely important in terms of managing your API limits. Please the section on Pushing data and batch / bulk operations for detailed explanations of this.
Batch Operations input structureCopy
The input stucture for batch operations varies depending on which operation is being used:
Create &/ Update Flow NamesCopy
These operations will automatically set up your Salesforce Flows for you.
On Record Create
On Record Update
On Record Create or Update
Be aware that your Flow name will be autogenerated. Your Flow will be available to view in the All Flows page.
The name of your Flow will be based on the Object prefix (which is automatically set to "Tray"), the name of the operation itself, and will include a random hash following it.
Note that the Object prefix can be changed under the Show Advanced Properties button in the trigger's property panel.
SOQL Query & SOSL Query operationsCopy
The Salesforce Object Query Language (SOQL) and Salesforce Object Search Language (SOSL) APIs can be used to search your organisation’s Salesforce data.
Generally speaking when using these query operations, you should use SOQL to query one operation at a time, and SOSL when you want to search text, email, phone fields, etc (basically when searching multiple objects simultaneously). This is why the latter is better to use when querying a relationship between objects and such.
Here are some points you need to consider when choosing between the two query operations:
Use SOQL when you know which objects the data resides in, and you want to:
Retrieve data from a single object or from multiple objects that are related to one another.
Count the number of records that meet specified criteria.
Sort results as part of the query.
Retrieve data from number, date, or checkbox fields.
IMPORTANT!: Please note that for for SOQL Query to accept your date references, the format MUST BE: YYYY-MM-DD. Please see the SOQL API Documentation site for more details.
Use SOSL when you don’t know which object or field the data resides in, and you want to:
Retrieve data for a specific term that you know exists within a field. Because SOSL can tokenize multiple terms within a field and build a search index from this, SOSL searches are faster and can return more relevant results.
Retrieve multiple objects and fields efficiently where the objects might or might not be related to one another.
Retrieve data for a particular division in an organization using the divisions feature.
Retrieve data that’s in Chinese, Japanese, Korean, or Thai. Morphological tokenization for CJKT terms helps ensure accurate results.
The language used is crucial for your search patterns. In principal, it is extremely similar to SQL in text style.
With the above taken into consideration, below is an example of a SOQL query, which also involves using the Date & Time helper connector (notice how the 'Format' has been deliberately set up to suit Salesforce protocols):
This image demonstrates the way one may use the SOSL query operation to run through 'All Fields' available, in order to return any and all account names and IDs found (unlike the above query example, this is tailored towards multiple )
For further information regarding the Salesforce Object Query Language (SOQL) and Salesforce Object Search Language please see their API Documentation site for more details.
Using the Raw HTTP Request ('Universal Operation')Copy
IMPORTANT!: Please note that the Raw HTTP Request only works with REST API endpoints. You cannot make requests to SOAP API endpoints.
As of version 7.5, you can effectively create your own operations.
This is a very powerful feature which you can put to use when there is an endpoint in Salesforce which is not used by any of our operations.
To use this you will first of all need to research the endpoint in the Salesforce API documentation, to find the exact format that Salesforce will be expecting the endpoint to be passed in.
Note that you will only need to add the suffix to the endpoint, as the base URL will be automatically set (the base URL is picked up from the value you entered when you created your authentication).
IMPORTANT!: Accessing the base URL: If you need to access the base URL (e.g. for making a Full URL Raw HTTP requests) then the following information will be useful. The base URL for Salesforce is your Salesforce instance URL. It will most likely be similar to: 'https://abc123.salesforce.com' where 'abc123' is your Salesforce instance name. You may access your Salesforce instance URL within a workflow by using jsonpath to extract it from the authentication parameters** '$.auth.instance_url'**.
For example, say that the 'Get Job Info' operation did not exist in our Salesforce connector, and you wanted to use this endpoint, you would use the Salesforce API docs to find the relevant endpoint - which in this case is a GET request called: /services/data/vXX.X/jobs/ingest/jobID.
PLEASE NOTE: You will need to enter the correct API version (e.g. 'v51.0') and the correct job ID (e.g. '7504S000001nOJkQAM') in order to build a valid endpoint for the URL.
More details can be found here.
So if you know what your method, endpoint and details of your query parameters are, you can get the Salesforce job information with the following settings:
Method: GET
Endpoint: /services/data/v51.0/jobs/ingest/7504S000001nOJkQAM
Query Parameters: None
Body Type : None : null
Final Example outcome being: https://abc123.salesforce.com/services/data/v51.0/jobs/ingest/7504S000001nOJkQAM
