In this guide you'll learn how to pass data through Appian Process Models.
Each design object has a specific domain prefix that is used to reference their associated variables.
Within the process model designer you will encounter additional domain prefixes that are unique to process models. These additional prefixes grant you access to data used throughout the process model, including process model properties, individual task/node properties, individual instance properties, and node functional data.
Examine how data flows in the life cycle of a process instance. In the following example, we have initiated a record action as a registrar to add a new vehicle to a vehicle database.
When we connect different nodes together in a process model, we assemble different features together in a specific order. In the above example, the process execution engine executes the start form first, then the script task, and so forth, all the way to the end node.
Every node in a process model performs a specific function, based on the inputs and outputs it is provided. For example, the Write Records node writes a set of Record information to the database. The Write Records node can’t just write any record, however, it writes a set of record information that the process model specifies. If the node is not given an input, the write records node doesn’t know what to do and will error out.
Every type of node (Script Task, Write Records, etc.) has different inputs and outputs. These inputs and outputs are referred to as Activity Class Parameters. Activity Class Parameters are effectively local variables for their associated node and their data does not persist in memory unless explicitly saved to a process variable. These parameters are managed in the Data tab of a node which is split into two corresponding Node Inputs and Node Outputs sections. Node Inputs define the data being passed into the node, and Node Outputs define the data available to be passed out of the node.
Some nodes have Activity Class Parameters that are required for the node to function (like the Node Input “Records” in a Write Records node). Some nodes have specific outputs defined as a result of the node’s function. For example, the Write Records node has three defined results:
Other nodes, however, do not have defined results and require different configurations. Two primary examples of nodes without results are Script Tasks and User Input Tasks.
Take a closer look at the data flow through a User Input Task where the data for the process variable, pv!vehicle, is modified via user interaction on an interface.
Interfaces can’t directly use process variables, so in order for the Supervisor Review interface to receive and manipulate the data from the process variable, the data must first be mapped to the Node Inputs which directly correspond to the rule inputs of the form. Once mapped the data can flow from process variable to node input to rule input to node output finally back to process variable.
Understanding that the data needs to be passed from process variable to activity class parameter to rule input and back again, consider the configuration required to make this work. After adding the form to the Form tab of the User Input Task and allowing the process modeler to automatically create Activity Class Parameters for the associated rule inputs, the node inputs must be configured.
Here, the value parameter for the node input vehicle is pv!vehicle. The value parameter tells the process to take pv!vehicle and pass it into ri!vehicle of the form. If the value parameter is left blank, then the form will launch with a null value for ri!vehicle.
Next consider how the data returns from the rule input of the form back into the process variable. This is addressed by the save into parameter for the node input vehicle. The process assigns the “Review New Vehicle” task to a supervisor, who then opens the form, changes some vehicle information, and hits submit. Since the supervisor is working within the interface, all of those changes are stored in ri!vehicle of the interface, not in pv!vehicle of the process model.
The save into parameter for the vehicle node input allows the changed information in ri!vehicle on the form to be passed back into the process as pv!vehicle. Until the supervisor hits submit, pv!vehicle is the older, outdated version of the vehicle information. Thus, if the save into parameter is left blank, the process variables will not receive any changes from the user input task and the process will continue as if the user input task had no impact to the data at all.