Working with test data
IntroductionCopy
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)
You may find the following dev tools useful in terms of helping you create test data:
The Ops Explorer allows you to explore input and output schema for different triggers and service connectors. You can also use it to generate dummy payloads.
The CAPI Form Builder allows you to make live calls to 3rd party services and receive actual responses (note that you will be interacting with live data if you use this tool!)
Service / webhook-triggered workflowsCopy
Triggering events in the 3rd party serviceCopy
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 clientCopy
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 workflowsCopy
Pulling data from sandbox accountsCopy
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:
Replace the scheduled trigger with a manual trigger or massively reduce the interval to e.g. 5 or 10 minutes
Add / edit test data as required in the 3rd party service
Manually trigger a run of the workflow, or wait for the next scheduled run
If desired, make more edits to the test data and wait for the next scheduled run
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 connectorCopy
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:
The data returned by this step can then be accessed downstream using jsonpaths such as $.object-helpers-1.result.company
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