Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Current »

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 lets you 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 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

When you choose to create a workflow from scratch you will be presented with the following view, where you can select the apps 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

  • Clicking the button (“Use single” in our case, otherwise labeled “Connect”)

Adding blocks

You will then be presented with the workflow editor, which we will use to build the workflow. Here 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 *.

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 information 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 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 text 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 data type for this field, by clicking the pencil icon.

You are now able to 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!

Step 3: Running the workflow

  • No labels