In this article we will describe the process for creating a simple workflow from scratch.
For demonstration purposes, we will create a workflow using the “Test” application.
The Test app uses a dummy API, that allow you to GET and POST some data for testing purposes, but without actually changing data.
If you have never set up a workflow before we encourage you to follow the steps in this guide to create a simple workflow with the Test app. Since the Test application just uses dummy data there is no risk involved.
To do so:
Add the Test application to your account, as shown previously in step 1.
The Test app does not require any API credentials to be entered - simply add it to your account.Then proceed to create a new workflow from scratch, and copy the steps shown in this article.
These are the steps we will go though:
Select the app(s) to use in the workflow
Add the blocks that we need
Configure the blocks for our purpose
Configure the mapping
Select the app(s) to use in the workflow
Choose the apps you want to connect in the list on the left.
In our case we will just be using one app, the Test app, both for getting and posting data.
After clicking the button (“Use single” in our case, otherwise labeled “Connect”) you will be presented with the workflow editor.
Adding blocks
Next we will add the blocks that will make up the workflow logic. As explained previously, a block is a re-usable, modular piece of code that executes one or more tasks.
On the left, you will see a list of available blocks for the applications you have selected, as well as several generic blocks, including Mapper, Code and Join. (These are described in separate articles, here.)
To start building the workflow, simply drag and drop the blocks you want onto the canvas.
For our demo workflow, we will need the following three blocks:
For our demo workflow, we will need:
A block to fetch employees data (from the Test API).
A mapper block to map data and fields between two data formats
A block to update employees (in the Test API).
Configure the blocks
Now that the blocks have been added, we need to configure them to our needs.
If you click each of the blocks you will see the available block settings (under the “Working Area” tab) for each block, which lets you to customize how the block functions. Some of these settings are marked as required information, with a red *.
Configure the following settings:
For the GetEmployees block, set “Amount to obtain” to 10, to limit the block to fetch data for 10 employees
For the Mapper block, set the source to be the GetEmployees block, and the target to the Post Employees block
For the Post Employees block, set the Datasource to be the Mapper block
Now is a good time to save the changes you have made. Click the save icon to save your workflow.
Next we will look at setting up the mapping, using the mapper block.
The Mapper block
Data coming out of one application will need to be reformatted before it is transferred to the destination application. That is where the Mapper block can be used.
The Mapper block lets you transform data and map fields between a source and a destination application.
Please note that the Mapper block is currently a work in progress, so you can expect the Mapper block to gain more features and improve going forward.
More info about the Mapper block can be found here.
Select the Mapper block, and click the “Map model” button.
When we click on Map Model, the Mapper block will ask the source and target blocks to give examples of the kind of data they use. The mapper block will use this information to dynamically construct a mapping screen. (You will see a green checkmark appear next to the GetEmployees block as data is pulled, before the mapping screen appears.)
The mapping screen can be thought of as a spreadsheet with two columns – one for the source application, and one for the target application. By connecting corresponding fields, you are building a map for how data should be transformed. And like in a spreadsheet, you also have the possibility to use functions, to concatenate fields, put things to upper case, date manipulation, etc.
Expand the area on the left, and the Target column on the right, as shown in the screenshot.
You can now drag and drop fields from the area on the left into the Source column, to specify how fields will be mapped to the Target column.
But you may notice you are not able to map the zip code field directly, because of a type difference:
The zip code field has a string type in the source model, but a number type in the target model:
To fix this we must change the type for this field, by clicking the little pencil icon.
You are now able to also map the Source zip field to the Target zip field.
Save the mappings, and then save the workflow.
So, to summarize, this workflow is going to get (dummy) employee data out of the Test API, remap it (into an identical data format), and then upload the employee data back to the Test API.
Let’s run it!