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.
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.
Trigger
Every process flow starts with a trigger - when should this flow run? In process flows, trigger options are defined using the trigger shape.
Data source
Consider the following:
Which third-party application are you pulling data from?
Have you installed a connector for this application?
Have you added an instance (or multiple instances) of this connector?
In process flows, a data source is defined by adding a connection 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 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.
In process flows, existing payload-level custom scripts are added using the script shape. This is an advanced feature - very often, standard field mappings and transformations 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 handle this - or are field-level custom scripts required?
In process flows, field mappings and (if required) field-level custom scripts are applied using the map shape.
Data destination
Consider the following:
Have you installed a connector for this/these application(s)?
Have you added 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 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 page to make sure you understand how this works.
Last updated