# Approaching your first process flow
## Introduction
The flexibility of **process flows** means that there's no 'one size fits all' approach - everyone's requirements are different, and the scope is huge. This level of flexibility is a great advantage but on the flip side - where do you start?
Here, we outline the bare bones of a process flow so you know what to consider as a minimum when getting started for the first time.
## Testing
A scratchpad area will be available soon. In the meantime, we suggest registering for a sandbox account and experimenting there.
Make sure you create instances with credentials for your third-party application sandbox accounts, rather than live ones!
## Key elements of a process flow
In their simplest form, process flows are defined to receive data from one third-party application and send it to another third-party application, perhaps with some data manipulation in between. Key elements are summarised below.
{% hint style="warning" %}
Process flows allow you to build highly complex flows with multiple routes and conditions. Here, we're considering an entry-level scenario to highlight key items as you get started with process flows.
{% endhint %}
Trigger
Every process flow starts with a trigger - when should this flow run? In process flows, trigger options are defined using the [trigger ](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/trigger-shape)shape.
Data source
Consider the following:
* Which third-party application are you pulling data from?
* Have you [installed a connector](https://doc.wearepatchworks.com/product-documentation/connectors-and-instances/working-with-connectors/installing-a-connector) for this application?
* Have you [added an instance](https://doc.wearepatchworks.com/product-documentation/connectors-and-instances/working-with-instances/adding-an-instance) (or multiple instances) of this connector?
In process flows, a data source is defined by adding a [connection](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/connector-shape) shape and selecting a connector **instance** and **endpoint**.
Filters
Do you need to refine data in the current payload, before it's processed any further? In process flows, filters are defined using the [filter](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/filter-shape) shape.
Scripts
Does the data you pull (i.e. the payload) require advanced manipulation before processing continues? If it does, and you have development expertise in-house, you can write and apply [payload-level custom scripting](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-shapes/advanced-shapes/script-shape).
In process flows, existing [payload-level custom scripts](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/broken-reference) are added using the [script](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-shapes/advanced-shapes/script-shape) shape. This is an advanced feature - very often, standard [field mappings and transformations](#field-mappings) are enough to sync data as needed.
Field mappings
Consider the following:
* Where should field values from the source data be placed in the destination application?
* Do you need to manipulate source field values before they are synced to the destination? If yes, will standard [field mapping transformation functions](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/map-shape/working-with-field-transformations/available-transform-functions) handle this - or are [field-level custom scripts](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/map-shape/working-with-field-transformations/available-transform-functions/other-transform-functions/script-transform-function) required?
In process flows, field mappings and (if required) [field-level custom scripts](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-shapes/advanced-shapes/script-shape) are applied using the [map](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/map-shape) shape.
Data destination
Consider the following:
* Have you [installed a connector](https://doc.wearepatchworks.com/product-documentation/connectors-and-instances/working-with-connectors/installing-a-connector) for this/these application(s)?
* Have you [added an instance](https://doc.wearepatchworks.com/product-documentation/connectors-and-instances/working-with-instances/adding-an-instance) (or multiple instances) of this/these connector(s)?
In process flows, the data destination is defined by associating an instance with a [connection](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/connector-shape) shape.
## Process flow versions
Process flow can be associated with three version types: draft, deployed and inactive. Before you get started building process flows, we advise reading our [Process flow versioning](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-versioning) page to make sure you understand how this works.