# 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 ](/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/trigger-shape.md)shape.
Data source
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**.
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](/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/filter-shape.md) 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](/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.
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](/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.
Data destination
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.
## 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.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/approaching-your-first-process-flow.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.