The capabilities described on this page are included in Appian's standard capability tier. Usage limits may apply. |
If your business uses common actions within a larger robotic task, you might find it useful to create and integrate robotic subtasks into your robotic task development. Robotic subtasks can be built to serve common purposes between multiple robotic tasks, such as logging into an application, retrieving files and sending them to Appian, or scraping data.
This page describes what a robotic subtask is, how it works, and how to use it in other robotic tasks.
A robotic subtask is any robotic task that's executed within the robotic task definition of another robotic task. Any robotic task can be run as a robotic subtask, and a robotic task can contain multiple robotic subtasks. It can even contain a robotic subtask that contains its own robotic subtask. See Subtask relationships to learn more about how the robotic tasks relate to each other.
Robotic subtasks are recommended where common steps are performed. This enables developers to more easily collaborate, re-use, and design more modular robotic tasks. Learn more about when to use robotic subtasks.
Robotic subtasks operate in ways similar to subtasks in Appian process models. However, there are some important differences:
You'll use the Execute robotic subtask action to configure and launch a robotic subtask from within a parent robotic task. It specifies which robotic subtask to call and indicates the data to be passed in and out of the subtask.
Throughout this page, the robotic subtask may be referred to as the child robotic task, while the robotic task that calls the subtask is referred to as the parent robotic task. These terms help show the relationship between the robotic tasks.
You'll configure the parent robotic task to use the Execute robotic subtask action to establish this relationship.
Because any robotic task can be used as a subtask, it's possible to have multiple levels of subtasks. For example, if robotic task C is used as a subtask in robotic task B, robotic task B can still be used as a subtask in robotic task A. Effectively, robotic task A contains two subtasks, but robotic task C is two levels down. Keep this relationship in mind as you learn more about how subtasks behave.
Represented visually, the levels would appear as:
The steps below describe how to set up a robotic subtask.
Create and save the robotic task you intend to use as a subtask.
Note: The robotic subtask should contain all of the components it needs to execute successfully and independently, such as variables and support files.
When used as a subtask, certain configurations of a robotic task may behave differently:
Setup and Cleanup: Robotic subtask' Setup and Cleanup sections are always skipped during execution. Any setup or cleanup activities that are needed for the main automation should be incorporated into the highest level robotic task's Setup and Cleanup sections.
Environmental variables: Robotic tasks use their respective environmental variables. The parent robotic task uses parent environmental variables, while the subtask uses subtask environmental variables.
Credentials: The parent robotic task's permission tags define which credentials are accessible during execution. If, in the subtask, users select Any available credential, the robotic task chooses from the credential entries that are available to the parent robotic task. In the subtask, if users select Specific credential but the credential is not available to the parent robotic task due to mismatched permission tags, an error is logged. Credentials are not released until the Cleanup section of the parent robotic task is run.
Workflow libraries: Workflow libraries are supported for subtasks. If there are different versions of a workflow library being used between the parent robotic task and the subtask, the higher version is automatically used during execution.
Robot tags: The parent robotic task permission tags determine which robots are available for execution. The subtask's permission tags don't need to match the execution robot's permission tags, as long as the parent robotic task's tags match the robot's.
Robot tags: The parent robotic task permission tags determine which robots are available for execution. The subtask's permission tags don't need to match the execution robot's permission tags, as long as the parent robotic task's tags match the robot's.
Note: Permission tags are changing. See the Unification Guide for details about these changes.
To share credentials between the parent robotic task and the child robotic task, a reserved credential should be passed using a robotic task variable. This section describes the steps to achieve this.
First, create a robotic task variable of type Credential
in the parent robotic task to store the credential. Note that this data type is unique to RPA and can't be used in expressions, casting, or referenced as a parameter in a process model.
To reserve a credential:
To pass the reserved credential to the robotic subtask:
To use the reserved credential in the robotic subtask:
For input variables where you are evaluating an expression, if the value being passed to the child parameter does not match the data type of the variable, Appian will attempt to cast the data automatically.
If the automatic casting is invalid, the robotic task will throw the following error in the log to indicate the type mismatch:
Unknown error. Please contact administrator with the following message: Could not cast from (Variable Type) to (Variable Type). Details: CastInvalid.
When requesting an execution, the account that is running the automation needs to have access to the parent robotic task and subtasks through appropriate permission tags. For example, if a service account had a tag removed that also removed its access to the subtask, the parent robotic task would fail to execute with the following message: The robotic task or one of its dependents does not exist, has been deleted, or you do not have permission to access it
.
Robotic subtasks execute as part of the main parent's robotic task execution. Their definition is set at the time the robotic task execution was requested, and any changes to the subtask afterwards will not be reflected in the pending execution. Robotic subtasks are run synchronously, meaning the parent robotic task will wait for the subtask actions to complete before resuming the rest of the robotic task definition.
The subtask's execution log is contained in the parent robotic task's log. Therefore, when a robotic task is run as a subtask of another automation, that execution will not display in the subtask's own execution log. However, when the robotic task is executed as an independent robotic task, its execution appears in its own execution log.
When you're manually executing a subtask or using the debugging tool, you can open the subtask in its own tab and see all of its execution steps, just like the parent robotic task.
Here are some key points to keep in mind when you're viewing subtasks:
Robotic Subtasks