Skip to main content

Working with test data

Introduction​

You will need to run test data through your workflows in order to confirm that they are working 100% as intended.

Exactly how you will do this depends on the type of workflow you are building and how data comes in.

However you run your test data the principle you should follow is to try and replicate the data exactly as it will come into your workflow.

Here we will discuss the following common workflow types:

  • Service-triggered workflows (for when there is a dedicated Tray service trigger)
  • Webhook-triggered workflows (for when there is no dedicated Tray trigger for a particular service)
  • Scheduled trigger workflows (polling)

Service / webhook-triggered workflows​

Triggering events in the 3rd party service​

If your workflow is triggered by events occurring in a 3rd party service (e.g. updated opportunities in Salesforce) two approaches are:

  • If available, make use of the ability to send test webhook payloads from the 3rd party Service
  • If you have a sandbox account for the 3rd party service, fill it with test data and add / edit / move records in a way that will trigger the webhook conditions, thus triggering a run of your workflow

Sending test payloads with a REST API client​

If neither of the above are feasible, an alternative option is to use a REST API client such as Postman or Thunderclient for VSCode to send a dummy payload to the webhook url of your workflow.

There are two important points to note with this approach:

  • If you are using a dedicated Tray Service trigger then you will need to temporarily swap it out for a Webhook trigger
  • You will need to research the 3rd party API documentation to find accurate payload schemas for the events that will be triggering your workflow

Scheduled trigger workflows​

Pulling data from sandbox accounts​

When using a scheduled trigger you will very often be using 'get records' type operations in order to pull a bunch of records which match certain criteria.

A good strategy here is:

  1. Replace the scheduled trigger with a manual trigger or massively reduce the interval to e.g. 5 or 10 minutes
  2. Add / edit test data as required in the 3rd party service
  3. Manually trigger a run of the workflow, or wait for the next scheduled run
  4. If desired, make more edits to the test data and wait for the next scheduled run
  5. Disable the trigger when testing is complete, until you are ready to move to production and go live

Creating test payloads with the Object Helpers connector​

If you are unable to use a sandbox account, you can make use of the Object Helpers 'JSON parse' operation to manually generate test data.

You can do this by simply pasting a test payload into the 'source' box of the operation properties panel:

json-parse-data

The data returned by this step can then be accessed downstream using jsonpaths such as $.object-helpers-1.result.company

caution

This method is not ideal as, once you have completed testing, you will have to replace the $.object-helpers-1.result jsonpaths with the appropriate service jsonpaths e.g. $.salesforce-1 or $.hubspot-1