To create well-formed workflows, you need to understand the rules for adding activities and connecting them. In addition, you need to understand how to manipulate workflow data.
When adding activities to a workflow, follow these rules:
A workflow must have only one Start activity and one Finish activity.
A workflow can have zero or more of the following activity types:
Each Branch activity must have a corresponding Merge activity.
When adding flow paths to a workflow, follow these rules:
With the exception of the Start activity, all activities can have one or more incoming flow paths. The Start activity cannot have any incoming flow paths.
The Finish activity cannot have any outgoing flow paths.
There can be only one flow path out of the Start activity. The flow path type must be forward.
There can be between one and five flow paths out of the Approval activity. The valid flow path types are approved, denied, refused, timedout, and error. At runtime, only one of the flow paths is executed.
There can be only one flow path out of the Log and Merge activities. The flow path type must be forward.
There can be two or three flow paths out of the Condition activity. The valid flow path types are true, false, and error. The true and false flow paths are required; the error flow path is optional.
There can be one or more flow paths out of the Branch activity. The flow path type must be forward for each path. At runtime, all the flow paths execute.
There can be between one and three flow paths out of the Rest activity. The valid flow path types are forward, error, and timedout.
The following table summarizes the rules for adding flow paths into and out of an activity:
Table 9-4 Number of Flow Paths Permitted for Each Activity
Activity |
Inbound Paths |
Outbound Paths |
---|---|---|
Start Activity |
0 |
1 must always be forward |
Finish Activity |
1 to n |
0 |
Approval Activity |
1 to n |
1 to 5. Approved, denied, refused, timedout, or error |
Log Activity |
1 to n |
1 must always be forward |
Condition Activity |
1 to n |
2 to 3. True and false are required; error is optional |
Mapping Activity |
1 to n |
1 |
Workflow Status Activity |
1 to n |
1 must always be forward |
Email Activity |
1 to n |
1 must always be forward |
Rest Activity |
1 to n |
1 to 3. Forward, timedout, error |
Integration Activity |
1 to n |
1 to 4. Success, timedout, error, fault |
Notify Activity |
1 to n |
1 must always be forward |
Branch Activity |
1 to n |
1 to n |
Merge Activity |
1 to n |
1 must always be forward |
The following table summarizes which activity types can be a source or target for each of the available flow path types:
Table 9-5 Flow Path Types Allowed for Each Activity
Activity |
Forward |
Approved |
Denied |
Refused |
Timedout |
True |
False |
Error |
Success |
Fault |
---|---|---|---|---|---|---|---|---|---|---|
Start Activity |
Source |
|
|
|
|
|
|
|
|
|
Finish Activity |
Target |
Target |
Target |
Target |
Target |
Target |
Target |
Target |
|
|
Approval Activity |
Target |
Source/Target |
Source/Target |
Source/Target |
Source/Target |
Target |
Target |
Source/Target |
|
|
Log Activity |
Source/Target |
Target |
Target |
Target |
Target |
Target |
Target |
Target |
|
|
Condition Activity |
Target |
Target |
Target |
Target |
Target |
Source/Target |
Source/Target |
Source/Target |
|
|
Mapping |
Source |
Target |
Target |
Target |
Target |
Target |
Target |
Target |
|
|
Workflow Status |
Source/Target |
|
|
|
|
|
|
|
|
|
Email Activity |
Source/Target |
|
|
|
|
|
|
|
|
|
Rest Activity |
Source/Target |
Target |
Target |
Target |
Source/Target |
Target |
Target |
Source/Target |
Target |
Target |
Notify Activity |
Source/Target |
|
|
|
|
|
|
|
|
|
Integration Activity |
Source/Target |
Target |
Target |
Target |
Source/Target |
Target |
Target |
Source/Target |
Source |
Source |
Branch Activity |
Source/Target |
Target |
Target |
Target |
Target |
Target |
Target |
Target |
|
|
Merge Activity |
Source/Target |
Target |
Target |
Target |
Target |
Target |
Target |
Target |
|
|
When you are creating a workflow, you can manipulate workflow data to suit the needs of your provisioning application.
The workflow uses a single process object to manage information about the process. A separate activity object is created for each activity in the workflow and form data is maintained for each activity that provides user interaction.
The data objects associated with each user interface control on a form (text field, drop-down list, and so forth) can be modified immediately prior to the execution of the corresponding activity (Start activity or Approval activity). In addition, this data can be retrieved immediately after execution of the activity. After control has been passed to the next activity, the form control data is no longer available. For this reason, the workflow provides a special object called flowdata that allows you to define your own data items. You can add your own variables to this object to keep track of information that is important to your workflow, including form data that would otherwise be lost.
The following table summarizes the categories of workflow data:
Table 9-6 Categories of Workflow Data
Data Object |
Lifetime |
Editable |
Creator |
---|---|---|---|
process |
Workflow |
No |
System |
activities |
Workflow |
No |
System |
activity forms |
Activity |
Yes |
System and workflow administrator |
flowdata |
Workflow |
Yes |
Workflow administrator |
NOTE:The workflow administrator is the person who creates workflow in Workflow Builder.
You can reference these objects in ECMAScript expressions. Script expressions in a workflow can at any time refer to data items that are bound upstream in the flow. However, workflow expressions cannot refer to data items that are created downstream (because these data items do not exist yet) or to data bound on other branches in a flow that supports parallel processing (because these branches could be executing concurrently with the current activity).
You can create a new data item on the flowdata object by specifying a post-activity target expression on the Data Items tab for the Start or Approval activities. If you specify a name for a new data item in the Target Expression column, this automatically creates the variable. Any activity executed after this activity can then access the data item.
For example, you might want to map the form field called reason to the target expression flowdata.myReason. The variable myReason then becomes a new data item that is available to all activities executed later in the workflow.
You can modify a data item by specifying a pre-activity expression on the Data Items tab for the Start or Approval activities. For example, to prepend a dollar sign to a price, you might map the following source expression to a target form field called Price:
"$" + flowdata.get('cost')
When the form displays to the user, the Price data appears as follows:
$xx.xx
Another example might be computing the total cost by adding the tax to the base cost. To do this, you could map the following source expression to a target form field called TotalCost:
Number(flowdata.get('cost')) + Number(flowdata.get('tax'))
All data in the flowdata object is maintained in XML, so you can create data items in a hierarchical fashion as well. For example, suppose you have a workflow form that allows a user to ask for access to two internal systems, one for accounts payable and one for receivables. Suppose the form has (among other fields) two Yes/No fields named Acct_Pay and Acct_Rec. In the post-activity data item mappings, you might create two mappings as follows:
Table 9-7 Complex Data Item Mapping Examples
Source Form Field |
Target Expression |
---|---|
Acct_Pay |
flowdata.SystemAccess/AcctPay |
Acct_Rec |
flowdata.SystemAccess/AcctRec |
This would create an XML element named SystemAccess with two child elements named AcctPay and AcctRec. One reason to structure data in this way is for clearer organization and management of data in complex workflows containing many forms and data items. To retrieve data from these hierarchies, the following syntax would be used:
flowdata.get('SystemAccess/AcctPay')
For complete details on building ECMAScript expressions, see Section 11.0, Working with ECMA Expressions.
All form controls you create are automatically made available for use in pre-activity and post-activity expressions on the Data Items tab for the activity that uses the form. For example, suppose you want to make a user’s entry data in control ACONTROL on form AFORM in AACTIVITY available for use in a subsequent activity. To do this, you would select AACTIVITY in the workflow, select the Data Items tab, and click the Post Activity tab. Next to the source form field ACONTROL, you would then enter a target expression in the following format:
flowdata.my_ACONTROL
Any subsequent activity in the workflow would then be able to access this data by using pre-activity source expressions such as these:
flowdata.get('my_ACONTROL')
flowdata.getObject('my_ACONTROL')
You can also move flowdata values into form controls. The simplest case is moving a single text value into a form control. In the example above, suppose ACONTROL is a simple text entry field. In this case, to move it into another text entry field in an activity called ZACTIVITY, you would select ZACTIVITY in the workflow, select Data Items > Pre Activity. Next to the target form field, you would then enter this source expression:
flowdata.my_ACONTROL
To move data into a form control, you need to be aware of type constraints. For example, you should not try to move text-based data into a numeric control.
In the mapping activity, the source expressions are evaluated before they are assigned to the target expression. If the source expression does not exist prior to the mapping activity, no value is assigned to the target expression.
For example, if flowdata.get(“textfield”) maps to flowdata.copyoftextfield and flowdata.get("copyoftextfield") maps to flowdata.copyoftextfield2, the value of flowdata.copyoftextfield2 is empty at the end of the mapping activity because the value of the flowdata.copyoftextfield is assigned only after the mapping activity.
To assign values to the target expression, you can use either of these options:
Multiple mapping-activities.
Single mapping-activity but repeat the source expression.
When you repeat the source expression, the flowdata.get(“textfield”) maps to flowdata.copyoftextfield and flowdata.get("textfield") maps to flowdata.copyoftextfield2.