# Working with test data

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.

##

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)

> **Info:** You may find the following dev tools useful in terms of helping you create test data:* The [Ops Explorer](https://tray.ai/documentation/developer/developer-tools/operations-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](https://tray.ai/documentation/developer/developer-tools/connector-tester) 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 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:

* Manually trigger a test run of the workflow (or wait for the next scheduled run)
* Add / edit test data as required in the 3rd party service
* If desired, make more edits to the test data and re-test
* 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](https://tray.ai/documentation/images/platform/automation-integration/testing-debugging/working-with-test-data/95uibtwVtw7C4YjpDkQQD_json-parse-data-e1bbb7ec9dcff0364ba6de8f7a889d04.png)
The data returned by this step can then be accessed downstream using jsonpaths such as `$.object-helpers-1.result.company`

> **Warning:** 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`