This page covers the various features and settings found in the dialog displays of process model properties. To learn more about the properties available for particular nodes and smart services, check out the individual node or smart service page. See process model properties if you are looking for more information regarding those tabs.
When multiple languages are enabled in the application, subtabs representing each enabled languages will appear.
The general tab can be found on every node & smart services and contains some or most the following parameters:
|Name||All activities||The name of the activity as it appears in the process modeler.|
|Description||All activities||A description of the node activity.|
|Task Display Name||All activities except for events||The name of the task (or activity) as it appears in a user task queue or task reports. Can be created using an expression.|
|Default Task Priority||All attended activities||The default task of a particular activity.|
|Quick Task||All attended activites||Sets an activity as a Quick Task, which will allow the activity to be available on-demand. When the activity has no incoming flow, the quick task will be available as soon as the process starts. If there is an incoming flow, the quick task will not be available until activitated by the incoming flow.|
|Persistent_ID||Certain events||(Read Only) and id associated with the activity. Used for email and JMS routing|
|End Condition||End event only||Simliar to the task display name, the name of a certain end event. Used when reporting on completed processes and the end event reached needs to be known.|
|Activity Chaining||Start event only||Allows activity chaining through the start event from a previous process.|
To see specific details about configurations in the data tab of a particular smart service, visit that smart service's reference page.
The node inputs section of the data tab support the display, creation and management of activity class parameters. Clicking on New Input will create a new activity class parameter. The selected nodes will appear highlighted.
From this the following field properties can be defined:
|Name||The name of the activity class parameter.|
|Type||The data type of the activity class.|
|Multiple||Checked if the activity class should support multiple values.|
|Value||The default value of the activity class. Evaluated at the start of the activity.|
|Required||Checked if the activity class should be required and the source of the activity classes value does not perform this validation.|
|Save Into||The process variable to save into. Can be selected or can be created by clicking on the New Variable icon . When you create a process variable using this method, the data type of the process variable you create cannot be changed. It is automatically assigned the same data type as the node input.|
Activity class parameters can be saved into process variables for use in other nodes, or they can provide data for the node to process.
When should I create a new activity class parameter? For attended nodes, where a user is expected to submit a form before continuing a process, create an activity class parameter for data produced from the form (read only data does not need an activity class parameter). For unattended nodes, where the system will execute the activity, create activity class parameters when the node requires additional values before executing (for example, CDT data for the write to data store entity smart service).
To delete an activity class parameter, select the node input and click the Delete Input button. If the activity class parameter is marked as required it will not be deleted.
Appian Smart Services include activity class parameters that have already been created to help you configure the activity. These cannot be deleted. However, depending on the smart service, additional activity class parameters should be created.
There is no guarantee as to the order in which expressions for node input values will be evaluated. It should be assumed that they are evaluated simultaneously. Therefore, you should not use or reference node inputs in an expression for the Value field of another node input within the same node.
Expressions for node input values are evaluated before expressions on the form. If the default values of form fields are mapped to activity class parameters, then they are evaluated at the same time as the node inputs. Therefore, they must not reference other activity class parameters.
You can save the value of an activity class parameter into a process variable of the same data type and cardinality (whether or not the variable accepts multiple values) using the Save Into field that appears on the property sheet associated with the activity class. If the process variable has the same data type but stores multiple values, it does not appear on the Save Into list. If so, you must use a custom node output to update the process variable with your node input data.
The save evaluation occurs at the end of the activity. This means, you cannot store a value in a process variable and use that updated value within an expression in the same node. Values entered into a form are only saved into their configured process variables when the user submits the form. As a result, you cannot report on values entered into a form which is saved but not submitted.
When saving a value from a custom data type, you have a number of options.
Node outputs can be used to store the data processed by your node using an expression. There are two types of node outputs: Results and Custom Outputs. The expression and save evaluations of either do not occur until the end of the activity.
Many smart services automatically generate result data. Results are activity class parameters, however, they cannot be used in expression editors outside of the node outputs section.
Results can be mapped to process variables similar to node input activity class parameters. However, depending on the result, designers can select a particular type of save operation.
If some other type of save operation is desired, designers can create a Custom Output expressions to append a single return value to a multiple value process variable with a compatible data type.
Custom node outputs provide a more flexible way to handle data than node inputs. Designers can create a new custom output by clicking New Custom Output. The selected nodes will appear highlighted.
Within a custom output's expression field, designers will have access to all process variables, activity class parameters, task properties, process properties, and process model properties.
Designers can select one of the following options from the Operator list. This list varies according to the data type of the target process variable. All data types allow you to use the following operators:
If the output is mapped to a process variable with a number or decimal data type, the following additional operators are enabled:
When selecting a process variable to save into, all process variables in the process model are available the Target field. If a single node output encounters an error that prevents it from writing its value to a process variable, none of the node outputs are written.
When multiple languages are enabled in the application, subtabs representing each enabled languages will appear.
The Forms tab allows a designer to associate an interface to an attended activity. The forms tab appears on all non-event and non-gateway activities.
For detailed information about how to design interfaces, including how to enable user interactions, how to save and validate user inputs, and how to submit user inputs to process, see the Interface Object page.
There are three ways you can interact with interfaces from the Forms tab. Only one method can be used at one time.
Designers who create their User Interfaces (UI's) before building their process models can use the Select an Interface option on the Forms tab. Existing interfaces can be searched in the picker below the radio buttons or through the directory icon .
Selecting an interface will generate a prompt to import rule inputs.
Any Type is not a supported data type in the process modeler. Rule inputs of data type No activity class parameters or process variables will be created for Any Type inputs, so you will have to manually map them.
Rule input names need to be at least three characters long in order to automatically associated with a new activity class parameter.
The values seen in the rule input table are activity class parameters of the same data type. Rule inputs can also be mapped via an expression by clicking on the expression editor icon .
Activity Class Parameters can also be configured directly from the Forms tab by clicking on the add icon in any rule input row. Besides the data type and multiple option being locked, Designers can perform the same functions within this modal as the data tab.
Designers who wish to start with the process model can create an interface that uses existing activity class parameters. By clicking the Create Interface icon a modal will appear.
In order to complete the interface creation, designers need to add a name, description, a rules folder to save into, as well as an Application to place the new interface. By default the Rule Input Name column will get the node input names, but these values can changed as desired.
Clicking OK will generate a blank interface with rule inputs added. To open the new interface, click the "Edit Interface" button on the forms tab.
The last option available to Designer is to write an expression. If you are opening an attended node that already has been configured prior to 17.1, the Process modeler will make an attempt to convert the original interface mapping configured via expression to the mapping grid shown above. If the process modeler cannot perform the conversion, for example if an expression was created passing arguments by position (e.g.,
rule!EXAM_uiFormNewResults(ac!cancel, ac!resultData, ac!resultViewers) ), then the form will appear in this expression editor.
This is the most labor intensive and error prone method for mapping interfaces to attended nodes. Appian recommends mapping interfaces using the first two options listed above, as it is easier to manage and configure.
The checkbox "Allow users to save a draft of in-progress tasks" creates a button on a user input form that will allow users to save a draft of their progress and come back to the form later. If a draft is saved, values will be stored in the activity class parameters. This allows users to save a draft of the data entered in a form, close their browsers, and come back to it later without losing information.
The checkbox "Capture location on submission (only supported in Appian for Mobile Devices)" captures the location where the User Input Task is submitted. The location is stored in a result called 'Submission Location' which can be accessed from 'Data Tab' under the 'Node Outputs' section. To reference the submission location elsewhere in the process model, the 'Submission Location' result parameter must be mapped to a process variable.
The Clear Icon next to the interface picker resets the interface rule invoked on the forms tab.
While this will clear out the interface used, any node inputs created during the process of interface integration will remain. If these node inputs are not desired anymore, they must manually be deleted from the data tab.
If you add or remove inputs from your interface, click the "Refresh" button on the forms tab to keep the mappings in sync.
The scheduling tab lets designers configure delay and periodicity values for the activity. The scheduling tab appears on all non-event and non-gateway activities.
You can start a node at a specific time on a certain date using the options on this tab. These options configure a timer event that starts when the node is first activated.
The node is then restarted every time the scheduled interval is reached, even if there are active instances of the node that are already running.
When an activity is scheduled, a clock marker is displayed on its border. The activity must be active in order for the schedule to be triggered. If an End Event is configured to terminate the process, the schedule is also terminated.
To schedule an activity, select the Don't start this node until: checkbox. You can specify either a time period for the execution of the node relative to the completion time of the last node or the date and time specified through an expression, which is evaluated at run-time.
To repeat an activity on a particular schedule, select the Repeat this node checkbox. Calendar options of the following periodicities are enabled: Daily, Weekly, Monthly, Yearly, or at an Interval.
When setting a recurring you can select the time zone used for the schedule, after selecting (or typing) the time of day. The
pp!timezone property is listed as the default Time Zone Context for setting a recurring interval. Designers can select the Repeat until checkbox to set the reoccurrence.
When activities have been configured to execute on a recurring schedule, it is possible to manually trigger or skip a recurrence.
The Assignment tab allows you to make a particular person or group responsible for a particular task within a process model. The assignment tab appears on all non-event and non-gateway activities.
An activity can be attended (requiring that a user perform a task) or unattended (using system logic to perform the task).
Designers can select users and groups for task assignment on this tab, or you can use a swimlane to set task assignment. If a lane assignment is configured, you must select the Override lane assignment for this node checkbox in order to specify different task assignees for this activity.
Designer should use either groups or a data-based user value (such as
pp!initiator) to assign an activity to someone.
For attended activities designers can specify whether or not the assignees of a task can reject it or reassign it by clicking the Set re-assignment privileges for assignees link. The following options are displayed (users with manager or higher privileges to the process can always reassign tasks):
|Select this option to deny an assignee the ability to reject or reassign the task.|
|Select this option to only allow users to reject the task. Users cannot reassign the task.|
|Select this option to allow users to reject or reassign the task back to one or more original assignees.|
|This is the default option and allows users to reject or reassign tasks to anyone.|
With an automated (unattended) activity, designers are given the option of either selecting Run as whoever started this process (the Process Initiator) or Run as whoever designed the process model (the Process Designer).
The unattended activity will be executed with the permissions of the selected user.
If an activity is run unattended, the relevant node inputs on the Data tab must have assigned values. The activity must complete within 60 minutes or the process will pause by exception.
Unattended activities are executed in a first-in-first-out order with a lower priority than attended activities and other direct interaction from users. Resources allocated to unattended activities are capped to ensure that the system is responsive to any users interacting with it.
There are two addition options on the Assignment tab allow designers to automatically correlate task assignments and assignees, as well as enable or disable email and mobile push notifications to task assignees:
If a task or process node is delayed for any reason, configurations in the escalations tab can automatically take a number of actions to solve the problem. An escalation can be configured for any attended node. Besides this configuration escalations can also be triggered manually, or by configuring an Escalation Timer Event.
Clicking the Add Escalation button . The Level 1 Escalation options appear. Multiple levels of escalation can be added.
If multiple escalation levels are selected, the timer on the second level escalation (and any subsequent level) will not start until the previous level is triggered.
The timer for the escalation is set by clicking the Configure link in the configure the timer event options. The Timer Event dialog box is displayed, which is identical in configuration to a timer event.
If an escalation is triggered, one of for actions can be triggered to occur:
The exceptions tab lets designers create alternative workflows from an activity based on configured conditions. The exception tab appears on all non-event and non-gateway activities.
When an exception event is added, a marker representing the event appears on the border of the activity. One or more events can be added to an activity. To create an exception flow, connect the marker to a flow within the process model. The connection between the marker and the flow is shown in red, to indicate an (alternate) exception flow.
Three exception types can be configured:
|Exception Type||Icon on Canvas||Description||Configured Like|
|Receive Message||Based on the receipt of a message from another process, stop this activity and proceed to the next node in the exception flow.||Receive Message|
|Timer||Based on a certain amount of time, stop this activity and proceed to the next node in the exception flow.||Timer|
|Rule||Based on whether a condition has been met, stop this activity and proceed to the next node in the exception flow.||Rule|
The Other tab allows designers to: configure multiple instances, set deadlines for node completion and, manage node execution options. The other tab appears on all non-event and non-gateway activities.
In your Process Model, you can run the same task multiple times. There is no set limit on the number of times that the task can be spawned, however, the default limit on the number of times a node can execute is 1000.
When a designer selects the Automatically run multiple instances of this node checkbox, they can choose to run instances by: integer value, a process variable that's a number, the number of values a process variable array value, or based of an expression.
Instances can run one at a time or all at the same time. When a designer selects Run all instances at the same time, a designer also has to choose when to move on:
You can set deadlines on each activity in a process model. This information is mainly used in reporting. For example, in a task report, a new data element can be added that lists the deadline of a task.
When a deadline is set within a node that is configured to run multiple instances, the deadline is applied to each instance of the node.
Select the Enable deadlines checkbox to enable deadlines. A deadline can be relative to when a task was issued, or it can be set to a specific date.
You can configure various runtime and data-retention options for a node, in the Execution Options group box.
|Refresh default values every time the task form is viewed||When this option is set, the default values in a task form are re-evaluated each time the task is viewed. If this checkbox remains cleared, the default values in the task form display the data only as it was evaluated when the task was first issued.|
|Confirmation URL||Deprecated Applies to custom pages.|
|Allow users to step back to this node from the next chained activity||Allow users to go back to a previous chained node.|
|When this node is completed: delete previously completed/canceled instances||All completed instances are deleted, except the current (most-recently activated) one. Once deleted, prior instance data can no longer be used for reporting or for the auditing of completed processes. If the node is a synchronous Subprocess Node, this option also deletes the process instance that was started by the Subprocess node.|
|Keep a record of the form as submitted for future reference||When this option is selected, the node inputs and node outputs are saved for future reference (such as auditing an exact copy of the form that was submitted). If this option is not selected, the node inputs and node outputs are deleted upon node completion. Another way to retain important information from a process (for archival purposes) is to save the relevant data into process variables. This allows you to create a report or view the process history to examine the data.|
|When this node is re-executed: do not create if active instances exist||If a node is reactivated (such as in a looping process flow) additional copies of the task only start if there are no other active copies of the task.|
|When this node is re-executed: Delete previous instances that are still active.||If this option is selected, relaunching a task causes all prior instances of the selected task to be removed from the system.|
Some activities also have a setup tab. The setup tab is used to pre-configure the activity with certain values and parameter. Many, but not all setup tabs, will impact what is seen on the data tab.
The following table describes briefly what can be found on each setup tab. Click on each activity link for more specific information.
|Activity or Smart Service||Description of the setup tab|
|Subprocess||Calls a process model from which designers can, among other things, associate parent process variable to child parameters|
|Execute Process Reports||Calls a process report and lets designers determine a max number of rows.|
|Send E-mail||Tab where designers create an e-mail template body, set from/to, and subject|
|HTML Doc from Template||Imports an HTML template and allows designer to associate process data to the template.|
|MS Word Doc from Template||Imports a Word Doc template and allows designer to associate process data to the template.|
|Open Office Doc From Template||Imports an Open Office template and allows designer to associate process data to the template.|
|PDF from Template||Imports a pdf template and allows designer to associate process data to the template.|
|Text Doc from Template||Imports an text file template and allows designer to associate process data to the template.|
|Call Integration||Calls an integration object and sets up the activities' data tab accordingly.|
|Call Web Service||Calls an external web service and sets up the activites' data tab accordingly.|
|Query Database||Setups the database connection and SQL statements to run.|
Events also have particular properties. The following table describes briefly what can be found on each event tab. Click on each activity link for more specific information.
|End||Setup||Setup a subprocess to start a child process when the end event is reached.|
|End||Result||Lets designers configure a send message event or terminate event|
|Receive Message||Setup||Determine and configure the type of incoming message to activate the node.|
|Receive Message||Result||Configures how data will be saved into the process.|
|Rule||Setup||Lets designers configure conditions to allow the flow to continue.|
|Send Message||Setup||Determines the receive message event that this node will reach out to.|
|Send Message||Data||Determine the data sent to the receive message event|
|Start||Triggers||Allows the start event to be triggered as a receive message event or a timer based event.|
|Timer||Setup||Works similar to the scheduling of other activities.|
In addition to a general tab, each gateway also includes a Decision tab. With the exception of the AND gateway, the decision tab contains a Conditions section where designers can create logical statements that control workflow. For more information about how to configure each gateway, refer to that gateway's page.
On This Page