|This content applies solely to Appian RPA, which must be purchased separately from the Appian base platform.|
If your business uses common actions within a larger process, you might find it useful to create and integrate robotic subprocesses into your workflow development. Robotic subprocesses can be built to serve common purposes between multiple robotic processes, such as logging into an application, retrieving files and sending them to Appian, or scraping data.
This page describes what a robotic subprocess is, how it works, and how to use it in other robotic processes.
A robotic subprocess is any robotic process that's executed within the workflow of another robotic process. Any robotic process can be run as a robotic subprocess, and a robotic process can contain multiple robotic subprocesses. It can even contain a robotic subprocess that contains its own robotic subprocess. See Subprocess relationships to learn more about how the robotic processes relate to each other. Additionally, robotic subprocesses have some limitations.
Robotic subprocesses are recommended where common steps are performed. This enables developers to more easily collaborate, re-use, and design more modular automations. Learn more about when to use robotic subprocesses.
Robotic subprocesses operate in ways similar to subprocesses in Appian process models. However, there are some important differences:
You'll use the Execute robotic subprocess action to configure and launch a robotic subprocess from within a parent process. It specifies which robotic subprocess to call and indicates the data to be passed in and out of the subprocess.
Throughout this page, the robotic subprocess may be referred to as the child robotic process, while the robotic process that calls the subprocess is referred to as the parent robotic process. These terms help show the relationship between the robotic processes.
You'll configure the parent robotic process to use the Execute robotic subprocess action to establish this relationship.
Because any robotic process can be used as a subprocess, it's possible to have multiple levels of subprocesses. For example, if process C is used as a subprocess in process B, process B can still be used as a subprocess in process A. Effectively, process A contains two subprocesses, but process C is two levels down. Keep this relationship in mind as you learn more about how subprocesses behave.
Represented visually, the levels would appear as:
You can't import or export a robotic subprocess with its parent robotic process at this time. In order to deploy robotic processes that leverage subprocesses to another environment, you will need to export and import all robotic processes separately.
The steps below describe how to set up a robotic subprocess.
Create and save the robotic process you intend to use as a subprocess.
The robotic subprocess should contain all of the components it needs to execute successfully and independently, such as variables and support files.
When used as a subprocess, certain configurations of a robotic process may behave differently:
Setup and Clean up: Robotic subprocess' setup and clean up sections are always skipped during execution. Any setup or clean up activities that are needed for the main automation should be incorporated into the highest level robotic process' Setup and Clean up sections.
Environmental variables: Robotic processes will use their respective environmental variables. The parent process will use parent environmental variables, while the subprocess will use subprocess environmental variables.
Credentials: The parent process's permission tags will define which credentials are accessible during execution. If, in the subprocess, users select Any available credential, the robotic process will choose from the credential entries that are available to the parent robotic process. In the subprocess, if users select Specific credential but the credential is not available to the parent robotic process due to mismatched permission tags, an error will be logged. Credentials are not released until the clean up section of the parent process is run.
Workflow libraries: Workflow libraries are supported for subprocesses. If there are different versions of a workflow library being used between the parent robotic process and the subprocess, the higher version will automatically be used during execution.
Resource tags: The parent robotic process permission tags determine which resources are available for execution. The subprocess's permission tags don't need to match the execution resource's permission tags, as long as the parent process's tags match the resource's.
To share credentials between the parent process and the child process, a reserved credential should be passed using a robotic process variable. This section describes the steps to achieve this.
First, create a robotic process variable of type
Credential in the parent robotic process 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 subprocess:
To use the reserved credential in the robotic subprocess:
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 process 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 2>. Details: CastInvalid.
When requesting an execution, the account that is running the automation needs to have access to the parent process and subprocesses through appropriate permission tags. For example, if a service account had a tag removed that also removed its access to the subprocess, the parent process would fail to execute with the following message:
The robotic process or one of its dependents does not exist, has been deleted, or you do not have permission to access it.
Robotic subprocesses execute as part of the main parent's robotic process execution. Their definition is set at the time the robotic process execution was requested, and any changes to the subprocess afterwards will not be reflected in the pending execution. Robotic subprocesses are run synchronously, meaning the parent process will wait for the subprocess actions to complete before resuming the rest of the workflow.
The subprocess's execution log is contained in the parent process's log. Therefore, when a robotic process is run as a subprocess of another automation, that execution will not display in the subprocess' own execution log. However, when the robotic process is executed as an independent process, its execution will appear in its own execution log.
If you use the debugging tool, subprocesses will appear as an action group within the execution preview and can be interacted with like other action group, such as setting breakpoints and disabling actions.
When a parent robotic process containing subprocesses is exported, the subprocess workflows and dependencies are not included in the ZIP file. In order to deploy to other environments, you will need to separately export the subprocess and its dependencies.
On import, the system checks for missing precedents, including references to robotic subprocesses. Therefore, it is recommended to import a robotic subprocess first, and then proceed importing the parent process.
On This Page