Invoke Workflow

Invoke Blocks are top level diagram components (like Sequences). The difference between Invoke Blocks and Sequences is that Invoke Blocks are not used to store actions.

Like the name suggests, Invoke Blocks are used to “invoke” (or more simply put - run) other workflows. You can “run” any kind of compatible .tapflow file (workflow), both internal (located within the current solution) and external (located in another solution or on the file system). So, simply put, the Invoke Block can be looked at as an action that executes a whole other workflow.

This segmentation is especially useful for designing modular automation solutions, where you can split automation logic into different, well-organized containers (or workflows). With the Invoke Block element, users can freely execute these components according to their requirements.

Invoke Block can be inserted within the diagram similarly to Sequences (using drag & drop).

The picture above displays an Invoke Block. Using the dropdown button you can quickly select one of the workflows from the current solution or you can browse for external workflows (.tapflow files) as well.

Note: You can also directly use the textbox area to manually input a workflow filename to be executed. Please note that values within the textbox area are used as expressions - so any string will need to be contained within quotes.

The Invoke Block features two additional buttons:

  • Show Workflow - used to display the currently selected workflow (this only works for workflows from the currently loaded solution). Clicking it will focus the designated workflow (or open a new tab for it if it’s not currently displayed).

  • Arguments - used to display a popup for setting workflow arguments.

Arguments

From a functional point of view, arguments are similar to variables (in that they have unique names, data types and values). The main difference between variables and arguments is their purpose: to facilitate data transfer between workflows, for both input and output.

In order to achieve this, arguments have an extra attribute assigned to them: Direction. This can either be Input or Output, depending on the purpose of the argument. Input arguments are used to “inject” or transfer data into a workflow from an external workflow, while output arguments are used to “export” or transfer data from the current workflow to an external workflow.

Similarly to variables, arguments are global within the scope of the workflow they are defined in. To be used properly, these need to be defined as part of the workflow and according to their designated purpose.

Arguments can be created similarly to variables, using the dedicated Arguments pane:

Please note that you are required to save the solution after updating the arguments within a particular workflow in order for the changes to be reflected throughout the whole project.

Using arguments with Invoke Blocks

Once properly defined, arguments can be used with Invoke Blocks in order to transfer data between the invoking workflow and the invoked workflow. This can be done by clicking the Arguments button from the target invoke block:

This popup allows users to manage how data is transferred between workflows via arguments.

All arguments attributes are read only at this point since they have been defined externally (in the invoked workflow). Users can only change the values that the arguments will use.

The above example shows using both Input and Output arguments. The arg1 and arg2 arguments are assigned the values of value1, respectively value2 (these are both normal variables from the current workflow). Thus, the date stored in the value1 and value2 variables will be transferred to the invoked workflow - and can be accessed in the invoked workflow via the arg1 and arg2 arguments.

Similarly, the outputArg is an Output argument - so it’s used to extract data after the invoked workflow has finished execution. The assignment direction is reversed for Output arguments - the sum variable (from the current workflow) is assigned whatever value is stored within the outputArg argument.

it is important that arguments that are being passed values receive evaluated expressions whose result is of the same data type. Assigning a string value to an Int32 argument will fail.

The article doesn't fully answer your question, or you want to find out more? Ask your question in the comments, on our community forum, or contact our support team or your account manager. Whatever works for you, your question will find its answer soon!

Last updated