Standard/Best Practices
Use Cases
Connecting to on-prem systems

The Advanced Tools

The Object Helpers connector

The Object Helpers connector can be used to help you create and manage data as 'objects' - an object being anything that you want to treat as a single entity with a set list of attributes - a CRM account, a set of company details, a contract, a customer, a shop order...

Object Helpers connector is a tidier way of dealing with data from multiple steps - i.e. put it all into an object so that all subsequent steps can grab it from the single object helper step.

You can also use it to create an object from all the data you've been gathering and send it to another workflow, using the Callable Trigger

Some examples of Object Helper operations are:

'Add key/value pairs' - can be used to create an object with a list of fields (keys) which can pull their values in from the output of other connectors

'Add value by key' - can be used to add an extra field (key) and value to an already created object

'Properties exist' - when a connector or trigger is returning data this can be used to check if a piece of data actually exists in what is being returned

'Parse json' - can be used to format e.g. xml data in a single line into correctly formatted json data that can then be used by other connectors

The Script Connector

The possibilities with the Script Connector are pretty much endless! You can use any data pulled from other connectors as input, and then run javascript functions on these variables. As it uses javascript, some developer input may be required for more complex operations!

One of the most common uses of the Script connector is to fine-tune and format data you have been gathering from other workflow steps. Any javascript code can be entered to carry out actions such as:

  • Convert your data from JSON to CSV before uploading it to another service

  • Format empty fields so that they are accepted by a database

Some good examples of the script connector being used can be seen in:

  • Our Script Connector documentation includes an example of creating dummy data (great for test purposes!) and how to format data so it meets the acceptance requirements of a database

  • Our AWS SQS documentation includes an example of pulling only specific values from a long JSON output and formatting them so they are simpler to use in other connectors

The Webhook Trigger

What is a webhook?

A webhook is simply a way to send data from 'application one' to 'application two' when a certain event takes place in application one. An example of a webhook would be when a new customer is added to Shopify, and the details of that customer are sent to another application.

The most common use for the Webhook Trigger in the Tray Platform is when we do not have a specific Trigger for a service and you want a workflow to be triggered when a particular event takes place in that service (for example when a new contact is added and you want their details to be sent to your workflow).

To set up a webhook all you have to do is:

  1. Create a Workflow with a Webhook Trigger

  2. Choose the action which triggers the webhook in the 3rd party service

  3. Enter your workflow public URL as the destination for your webhook

Then any time your workflow is triggered you can grab exactly the data you need:

If the service does not have a webhook available (such as Google Sheets) then you can use our Scheduled Trigger to periodically make checks for new information. We call this technique 'polling' and an example is demonstrated in our polling documentation

The HTTP Client

The HTTP client can be used to make calls to any REST API.

There are two main uses for this connector:

  • To make a call to an endpoint which is not yet used by any of the operations available in the connector for e.g. Salesforce, Hubspot, Trello, Airtable, etc.

  • If no Tray connector actually exists for a service, it can also be used to effectively build your own connector by creating a new authentication and passing a token as a parameter.

In this case it is likely that you will wish to use the HTTP Client in conjunction with the Webhook Trigger. This will enable you to create workflows which are also triggered by an event in the service for which there is as yet no pre-built trigger or connector.

The Data Mapper

Sometimes when working with data in your workflows, it is necessary to set up 'mappings' for your data. Two general scenarios which would necessitate the use of the Data Mapper are:

  • You are pulling data from a service and need the results to be formatted so as to update a particular field in a database with a value that is more helpful for the users of the database (e.g. 'landline call' and 'cellphone call' could both be mapped to 'phone call').

The Data Mapper has a Map Data operation for this purpose.

  • You wish to automatically pass data from one service to another by specifying a mapping 'table' so that e.g. the 'name' field in Service 1 is automatically mapped to the 'item' field in Service 2.

The Data Mapper has a Map Fields operation for this purpose.

The Delay Connector

The delay connector can be used to pause your workflow for a set period up to 10 minutes. This can be useful if you are waiting for the service you are querying to be updated.

The following example shows how you might use a loop connector with a delay to check until a new contact record is found:

Error Handling

One of the Tray platform's uniquely powerful features is the way it deals with handling errors in your workflows - when steps fail because of e.g. attempting to access missing data, or because authentication has expired. You can deal with these by ignoring minor errors, setting an alternative route for errors that need to be accounted for, or by stopping the workflow and setting up an alert process for major errors.

This is all explained in our section on Error Handling

Callable workflows

The Call Workflow connector and Callable Trigger are very powerful tools when used together.

Together they allow you to simplify your workflows by allowing you to work with a 'modular' approach - i.e. multiple workflows can gather data before calling one workflow which can carry out the actual processing tasks (calculations, updating of records etc.)

A basic explanation of setting up a callable workflow can be seen on the Callable Trigger page.

Please see our Using callable workflows documentation for more information on best practices and advanced usage - such as processing large volumes of data.