Difference between revisions of "Workflow Condition Examples"
From SmartWiki
| Line 1: | Line 1: | ||
| − | + | There are two rules that must be followed when adding multiple connectors to a workflow task that incorporate conditional logic statements: | |
| − | + | # Collectively, the conditions on each task must accommodate every possible permutation. | |
| − | There are two rules that | + | # Each condition must be mutually exclusive from every other. |
| − | # Collectively, the conditions on each task | ||
| − | # Each condition | ||
Let's discuss each of these rules. | Let's discuss each of these rules. | ||
| Line 31: | Line 29: | ||
===Example of Incorrect Configuration=== | ===Example of Incorrect Configuration=== | ||
| + | * Three [[types]] exist in a given [[UTA|application]], with [[Determining the typeid|typeIDs]] of 12345, 45678 and 67890. | ||
| + | * Two [[status]]es exists in the same application, with [[Determining the statusid|statusIDs]] of 888 and 999. | ||
| + | * The system administrator wishes to send emails via workflow if the record is in one of the above statuses. One email should be sent out if the type is 12345 or 45678 and a different email should be sent out if a different type has been used. | ||
| + | * Two connectors are set up on a workflow task with conditions of: | ||
| + | :* ''"@typeid@" in ("12345","45678") AND "@statusid@" in ("888","999")'' and | ||
| + | :* ''"@parent.statusid@" in ("888","999")'' | ||
| + | * The issue here is that both statements [[Boolean Operators|evaluate]] as '''true''' | ||
| + | |||
| + | |||
===Example of Correct Configuration=== | ===Example of Correct Configuration=== | ||
Revision as of 12:23, 16 July 2013
There are two rules that must be followed when adding multiple connectors to a workflow task that incorporate conditional logic statements:
- Collectively, the conditions on each task must accommodate every possible permutation.
- Each condition must be mutually exclusive from every other.
Let's discuss each of these rules.
Contents
Rule #1: Collectively, the conditions on each task must accommodate every possible permutation.
Example of Incorrect Configuration
- Three types exist in a given application, with typeIDs of 12345, 45678 and 67890.
- Two connectors are set up on a workflow task with conditions of:
- "@typeid@"="12345" and
- "@typeid@"="45678", respectively
- If the workflow is fired against a record associated with typeID 67890, the workflow will never progress to the next task.
Examples of Correct Configuration
- As above, three types exist in a given application, with typeIDs of 12345, 45678 and 67890.
- Three connectors are set up on a workflow task with conditions of:
- "@typeid@"="12345",
- "@typeid@"="45678" and
- "@typeid@"="67890", respectively
- Alternatively, two connectors with the following conditions could be set up:
- "@typeid@"="12345" and
- "@typeid@"!="12345" (not equal to "12345"), respectively
- In all cases, when using logical conditions on connectors, the conditions must encompass all possible logical scenarios.
Rule #2: Each condition should be mutually exclusive from every other.
Example of Incorrect Configuration
- Three types exist in a given application, with typeIDs of 12345, 45678 and 67890.
- Two statuses exists in the same application, with statusIDs of 888 and 999.
- The system administrator wishes to send emails via workflow if the record is in one of the above statuses. One email should be sent out if the type is 12345 or 45678 and a different email should be sent out if a different type has been used.
- Two connectors are set up on a workflow task with conditions of:
- "@typeid@" in ("12345","45678") AND "@statusid@" in ("888","999") and
- "@parent.statusid@" in ("888","999")
- The issue here is that both statements evaluate as true
