> For the complete documentation index, see [llms.txt](https://doc.wearepatchworks.com/product-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/approaching-your-first-process-flow.md).

# 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 %}

<details>

<summary><img src="/files/lEJVjx8Wl8aiVinNFHeA" alt="" data-size="line"> Trigger</summary>

<img src="/files/LkKnpjxekk87FEDEA6Iz" alt="" data-size="original">

Every process flow starts with a trigger - when should this flow run? In process flows, trigger options are defined using the [trigger ](/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/trigger-shape.md)shape.

</details>

<details>

<summary><img src="/files/ZwrogWXqyYBC1NviEd7W" alt="" data-size="line"> Data source</summary>

<img src="/files/hGKfYJLNjwK3jpSKWhO9" alt="" data-size="original">

Consider the following:

* Which third-party application are you pulling data from?
* Have you [installed a connector](/product-documentation/connectors-and-instances/working-with-connectors/installing-a-connector.md) for this application?
* Have you [added an instance](/product-documentation/connectors-and-instances/working-with-instances/adding-an-instance.md) (or multiple instances) of this connector?

In process flows, a data source is defined by adding a [connection](/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/connector-shape.md) shape and selecting a connector **instance** and **endpoint**.

</details>

<details>

<summary><img src="/files/OSjC4DiAICgGHd7vjtps" alt="" data-size="line"> Filters</summary>

![](/files/nbpCAkhQJDFHyA2irjJu)

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](/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/filter-shape.md) shape.

</details>

<details>

<summary><img src="/files/c83han8bx81qgc2tfFR9" alt="" data-size="line"> Scripts</summary>

![](/files/H3BwfhyEu6be2PoWJaVg)

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](/product-documentation/process-flows/building-process-flows/process-flow-shapes/advanced-shapes/script-shape.md).

In process flows, existing [payload-level custom scripts](broken://pages/XjuhzPfyPfhG1KOdE72F) are added using the [script](/product-documentation/process-flows/building-process-flows/process-flow-shapes/advanced-shapes/script-shape.md) shape. This is an advanced feature - very often, standard [field mappings and transformations](#field-mappings) are enough to sync data as needed.

</details>

<details>

<summary><img src="/files/wPSD9ZWEFthYgJiC2MJ1" alt="" data-size="line"> Field mappings</summary>

![](/files/yaPhRjIfewV8tTiXe4Vf)

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](/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/map-shape/working-with-field-transformations/available-transform-functions.md) handle this - or are [field-level custom scripts](/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.md) required?

In process flows, field mappings and (if required) [field-level custom scripts](/product-documentation/process-flows/building-process-flows/process-flow-shapes/advanced-shapes/script-shape.md) are applied using the [map](/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/map-shape.md) shape.

</details>

<details>

<summary><img src="/files/cFirEqM61Q58s7czWC56" alt="" data-size="line"> Data destination</summary>

![](/files/kDOyQlDwsV9TYdqOofvh)

Consider the following:

* Have you [installed a connector](/product-documentation/connectors-and-instances/working-with-connectors/installing-a-connector.md) for this/these application(s)?
* Have you [added an instance](/product-documentation/connectors-and-instances/working-with-instances/adding-an-instance.md) (or multiple instances) of this/these connector(s)?

In process flows, the data destination is defined by associating an instance with a [connection](/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/connector-shape.md) shape.

</details>

## 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](/product-documentation/process-flows/building-process-flows/process-flow-versioning.md) page to make sure you understand how this works.