Initiator Conditions and Iteration

The Initiator Editor consists of a series of conditions blocks identical to those found in the Conditions and Routing sections on each individual step.  The “add condition” button can be used to include an arbitrary number of initiator conditions.

Each individual condition can describe the relation between any number of variables using the same tools available in the routing section of individual steps.

When the workflow is executed each condition is evaluated against the user-given data, from top to bottom, in order.  Once a matching condition is found the Workflow immediately proceeds to the indicated step.

Each iteration cycle will execute the step with identical inputs, with the exception of any variables defined with the ‘iteration’ type.  These variables will be supplied with data derived from the specific iteration cycle.

The Iteration Variable field in the Iteration Options section accepts the normal set of ACP variable types.  If supplied with a simple numerical value (ex: 5), the step will iterate that number of times. If supplied with a JSON array (ex: [ { id: 123}, { id : 321 } ] ), the step will repeat once for every member of the array.

Once a Step’s Iteration Variable is changed from “omitted,” each Input across all sections gains access to the “iteration” data type.  If selected, this input will be supplied with data from the iteration cycle.  

In the case of simple numeric iteration, the data supplied will the iteration count, starting from zero.  

In the case of a more complicated JSON structure (ex: [ { id: 123}, {id : 321 } ] ), the entire object will be provided to the variable.  If only part of the structure is required, it can be accessed using the same semantics used to navigate JSON trees elsewhere. In the above example “{id: 123}” will be passed to the input by default, but if the input is configured with “id”, then only the value “123” will be selected.  Likewise, if the object contained an array, then “2.id” will select the third item’s “id” parameter.

Imagine a situation where a Workflow integrates between some 3rd party billing software and customer information stored in ProVision.  A simple workflow might accept user credentials (user names, account numbers, etc) and then verify them with ProVision, the billing software, or both. This simple workflow would return the user object on success, but an error on failure.

On its own, this doesn’t seem to do much, but this Workflow can be used as the first step of all subsequent Workflows, drastically cutting down on the overhead as well as allowing for easy single-point for maintenance in case of shifts in the underlying technologies.  

By creating simple workflows for very focused tasks one can build up a library of increasingly more complex combinations, allowing for very powerful results to be achieved in a compact space.