In this example, we will create a simple workflow to synchronize employee records between Talent Manager and Quinyx.
First, choose the two (or more) apps 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
...
If you have more than one instance of an application registered, for example a test and a production environment, you can choose which one you wish to connect to.
| Note |
|---|
It is a good idea to use a test environment when you build a new integration, if your app supports it. See this article for more info: Using a test environment |
On the screen you will have the option to give the workflow a name and description:
...
Adding blocks
...
| panelIconId | atlassian-note |
|---|---|
| panelIcon | :note: |
| bgColor | #B3D4FF |
...
. In our case we will just be using one app, the Test app, both for getting and posting data
Click the “Next“ button to proceed the next step.
Click the “Back“ button to return to step 1 of the Wizard.
Naming your Workflow
In step three you will be asked to name your workflow and give it a description.
...
When you have named your workflow, click the “Finish“ button.
The workflow editor
When you have clicked the “Finish“ button, you will be presented with the workflow editor.
This is where you will build your Workflow.
On the left side you can see the premade blocks available for the applications you have included in your integration. There are generic blocks, and a dropdown for each application that is a part of your workflow.
In the center you have the “Canvas”, You can drag and drop a block from the block menu onto the Canvas and configure them to fit your needs.
On the right hand side you have your settings menu. There is a main settings menu that can be accessed by clicking the blue cog icon on the top of the page.
...
If you click on a block, the settings menu will be changed to one that belongs to that block, not the entire workflow.
...
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 will be are described in more detail in separate articles, here.)
To start building the workflow, simply drag and drop the blocks you want onto the canvas.
In this exampleFor our demo workflow, we will need the following three blocks:
...
For our demo workflow, we will need:
A block to fetch employees from Talent Managerdata (from the Test API).
A block to update employees in Quinyx.A mapper block to map data and fields between the two applicationstwo data formats
A block to update employees (in the Test API).
<SCREENSHOTS>
...
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 on the canvas, you will see each has settings that allows the available block settings (under the “Working Area” tab) for each block, which lets you to customize how it works, with some fields being the block functions. Some of these settings are marked as required information . These are specific for each application, with individual documentation.
Before we do the mapping, we need to some simple configuration for the application specific blocks.
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.
| Info |
|---|
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 kind of data they use. The mapper block will use this information to dynamically construct a mapping screen.
| Info |
|---|
Please note that the Mapper block is currently a work in progress, so you can expect the Mapper block gain more features and improve going forward. |
(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 simply clicking on the 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 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 next to the field name.
...
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 HR app, we are going to map it based on the mappings we created, and then we are going to load it into QuinyxTest API, remap it (into an identical data format), and then upload the employee data back to the Test API.
Let’s run it!