 | Loading… |
|
|
Workflow elements
       
Workflow elements, tasks and blocks description
A diagram object is something that you put inside a workflow diagram. It can be a block which perform a specified operation, a transition, or some special objects that control the execution flow, like connectors and forks.
- Blocks are all the elements in workflow where work is performed: decisions, tasks, connectors, scripts, approvals...
- Tasks define what work is performed, connectors and decisions define process
- Each Pantheon form can be opened and a task with description is integrated on the form
- SQL queries with workflow variables values
- Run scripts with predefined functions from Pantheon and ARES

 |
Every workflow begins with Start. Only one Start block can exist in a workflow diagram. Allowed inputs: 0. Allowed outputs: 1. |
 |
Every workflow ends with End. Only one End block can exist in a workflow diagram. Allowed inputs: many. Allowed outputs: 0. |
 |
Error block is executed when an error occurs while executing the workflow diagram. Only one Error block can exist in a workflow diagram. Whenever an error occurs during the execution of the workflow diagram, the execution flow goes to the error block and then follow the path specified by it (the next block after the error block). You can use error block to perform some
clean up and then finish the execution of workflow diagram. Allowed inputs: 0. Allowed outputs: 1. |
 |
The source connector is a passthrough block to increase readibility of diagram. It makes execution flow to a target connector. Defines a jump to target.
If the execution flow reaches a source connector, then the diagram jumps to a target connector that is related to the source connector. The "relation" between the source and target connector is done by the text inside them. If the text is the same, the connection is established. For example, when the execution reachs a source connector labeled "A", then it jumps to the target connector labeled "A". This way you can have several source-target connections in a single diagram. Allowed inputs: many. Allowed outputs: 0.
|
 |
The target connector is a passthrough block to increase readibility of diagram. It receives execution flow from a related source connector. Target for the jump: Name of the source and target connects the jumps.
If the execution flow reaches a source connector, then the diagram jumps to a target connector that is related to the source connector. The "relation" between the source and target connector is done by the text inside them. If the text is the same, the connection is established. For example, when the execution reachs a source connector labeled "A", then it jumps to the target connector labeled "A". This way you can have several source-target connections in a single diagram. Allowed inputs: 0. Allowed outputs: 1.
|
 |
Connect transitions |



|
Connects one block to another, indicating the execution flow of diagram.
You use a transition (line, or wire) to connect a block to another. The transition indicates the execution flow, meaning that it flows from the source block to the target block. You create a transition by pressing down the mouse button at one link point (blue "x" in blocks) in the source block, dragging the mouse, and releasing the button at one link point in the target block. An arrow indicates the execution flow. You can create a normal transition, a side transition or an arc transition. All behave the same, the difference is only visual. You might not be able to attach a transition to a block, depending on the allowed inputs and outputs to the block. For example, if you try to create a transition that targets a Start block, you won't be able to do it, because a
Start block does not allow inputs. Some blocks allow multiple transitions as outputs. In this case, each transition must be labeled so that the diagram knows which transition must be used according to a specified condition. Only one transition is used for leaving a block. So, for example, two transitions might be connected to the output of a Decision block , but one should be labeled "yes" and the other should be labeled "no", so the diagram will know which transition to take according to the result of the decision condition. You can also specify a script for a transition, so that if the execution goes through the transition, the script is executed. In the transition dialog editor there is a tab named "Script" where you can write the script to be executed. When the transition has a script associated to it, a small lightning bolt icon is displayed at the beginning of the transition line.
|
 |
Creates parallel execution paths.
The fork object is used to create parallel execution paths. When a diagram of a workflow instance is started, there is a single execution path (started by the Start block ). If the execution reaches a fork block, the flow is split in several parallel paths (depending on the number of outputs in the fork) the execute simultaneously. At the end, all execution paths must finish at the same join object, otherwise the diagram is incorrect. Once all parellel execution paths finish, the main execution path starts again, from the join object. Allowed inputs: many. Allowed outputs: many.
|
 |
Ends parallel execution paths created by a fork object.
The join object is used to end and join parallel execution paths. When a diagram of a workflow instance is started, there is a single execution path
(started by the Start block ). If the execution reaches a fork block, the flow is split in several parallel paths (depending on the number of outputs in the fork) the execute simultaneously. At the end, all execution paths must finish at the same join object, otherwise the diagram is incorrect. Once all parellel execution paths finish, the main execution path starts again, from the join object. The main execution path will restart in the join object, going through the next block connected to its output. The main execution path will not restart until all execution paths created by the fork object are finished. Allowed inputs: many. Allowed outputs: 1.
|
 |
Creates task instances for users based on its task definitions.
Simple tasks for users to enter data, perform operations. The task block is one of the more important block types in a diagram. With task
block you can specify task definitions to be created for users. When the execution flow reachs a task block, it creates task instances for each task definition.
The task block itself is nothing but a set of task definitions. So, to use the task block, just create one or more task definitions and set the task definition properties. The workflow execution will stop at the task block until all task instances are finished. A task instance is finished when its status change to a completion status. After all task instances are finished, the execution flow continues, according to
the rules:
Task block has only one output: The execution flow goes through that path.
Task block has two or more outputs: Each output transition must be labeled with the name of a completion status. The execution path goes through the transition which is labeled with the same text as the task block output, which is the completion status of the task instance, i.e., if the task instance was completed as "approved" (a valid completion status, for example), then the execution path goes through the transition labeled "approved". If more than one task instance was created by the task block, either from the same task definition or from different task definitions, then the task block output will be the most common completion status among the task instances. For example, if two task instances finishe as "rejected" and one task instance finishes as "approved", then the task block output will be "rejected" and the execution path will follow the transition labeled the same. Allowed inputs: many. Allowed outputs: many (restrict to status list).
If more than one task instance was created by the task block, either from the same task definition or from different task definitions, then the task block output will be the most common completion status among the task instances. For example, if two task instances finishe as "rejected" and one task instance finishes as "approved", then the task block output will be "rejected" and the execution path will follow the transition labeled the same.
|
 |
It's a special task block which has a single approval task definition.
The approval block is just a task block which has a single task definition. This task definition is an approval task definition and it's a regular task definition with the difference that some properties are already initialized, with the subject, description, and specially the status list. The approval task comes with three valid status in status list: "opened", "approved" and "rejected". The approved and rejected status are completion status for the task. You can change the approval task definition properties as you want, just like in a task block. The only difference to the task block is that you cannot create more than one task in the approval block. Allowed outputs: many (restrict to status list). Allowed outputs: many (restrict to status list).
|
 |
Changes the execution flow acording on workflow variables.
Use a decision block to change the execution flow according to a boolean condition. When execution flow reaches a decision block, the condition of the block is evaluated. If it is true, then the execution path goes through the transition labeled "yes". If it is false, it goes through the transition labeled "no". Allowed inputs: many. Allowed outputs: 2 ("yes" and "no").
|
 |
Runs a separated workflow instance.
The run workflow block allows running a new workflow (subworkflow), separated from the current instance, in a synchronous or asynchronous way. To exchange information between the workflow instances, a variable mapping should be specified in the block definition. If "Wait until finished" flag is checked, the current workflow will wait the subworkflow to finish, in order to continue. The variable mapping is bidiretional in this case. If "Wait until finished" flag in unchecked, the current workflow will continue execution normally regardless of subworkflow status. Variable mapping is unidirectional only. The variable mapping lists which variables in the subworkflow will be updated. In the screenshot example below, variable "Company" in Shipment workflow (subworkflow) will receive the value of variable "CompanyName" in the current workflow. In the case of bidirectional mapping, when Shipment workflow finishes, the value of "CompanyName" will be updated again, with the value of variable "Company". Allowed inputs: many. Allowed outputs: 1.
|
 |
This block sends an e-mail using the existing e-mail notification settings. |
 |
Run an SQL statement in the database. Read/write data from/to DB. This block allows the you to specify an SQL statement in the database. You can use expressions in the SQL statement. SQL statement contains the SQL statement to be executed in teh database. Supports expressions.
Example: insert into tPA_Log (acvalue, acName) values ('[DocumentKey]', 'test');
Allowed inputs: many. Allowed outputs: 1.
|
 |
Shows a comment.
Adds a visual element to the diagram containing a fixed text. This block doesn't affect the behavior of diagram and is just used for visual indication. If you want text that supports expressions, use Text Block. Allowed inputs: none. Allowed outputs: none.
|
 |
Displays a dynamic text in diagram.
Use this block to display a text in any place of the diagram which can change according to workflow context. The main difference between this block and Comment block
is that it supports expressions and has no other visual elements besides the text itself. So you can use it to display dates, variable values, etc., over or close any other diagram object. Allowed inputs: none. Allowed outputs: none.
|
 |
Executes a script code.
The script block just executes a script code. In most cases, the script block
will have only one output. But you can also use multiple outputs from script block, it will depend on script result. You can define the script result by using result variable:
result := 'result1';
If you have more than one output, each leaving transition should have a label, and the execution flow will take the transition which label is the same as the script result. In the example above, you must have a transition labeled "result1" so the execution will follow that path. Allowed outputs: one (if the script does not return any value) or many (depending on possible script results). Allowed inputs: many.
|
|
|
|