The Workflow environment is really a high level programming environment that is entirely configured from a web browser.

 

When a Workflow Event is triggered, its child actions are executed. Each action can itself have child actions. A workflow is a grouping of events and their actions, which means a single workflow can contain many events. The order in which child actions should run can be configured.

 

Here is an example of the Tentative Booking Workflow for Calpendo, showing four Workflow Events that can be triggered, each having a child Workflow Action, and BiskitUpdate #5 Action having its own child Action.

 

tentativeWorkFlow

 

Both Workflow Events and Workflow Actions may have Conditions associated with them to define whether they should be run. If an Action is not run due to Conditions or fails due to some error then its child Actions are not run, although sibling Actions would be.

Workflow Header

When a Workflow is created the following properties are available.

 

Under the Details tab

 

Property

Value

Name

The name of the Workflow

Enabled

Whether the Workflow is enabled to run or not.

Main Type

The Biskit Type this Workflow is mainly associated with. This is used to determine where in the Workflow tree this Workflow will be displayed. This is only for display purposes and does not affect its functionality.

 

WorkFlowHeader

 

Under the Versioning Tab

 

Property

Value

Version

The version number of the Workflow

Created By

Who created the Workflow.

Created

The date the Workflow was created.

Updated By

Who last updated the Workflow.

Updated

The date of the last update of the Workflow.

 

workFlowVersion

 

Under the Comments Tab

 

Property

Value

Comments

An area to record comments about the Workflow

 

Workflows and Conditions

Workflow Events and Workflow Actions can both have Conditions.  

Workflow Events Conditions access a number of properties associated with the Event. These are different for each type of Event.

 

All Events have the following properties that can be accessed in their Conditions:

 

Example Properties

Notes

executedTime

The time the Event was executed.

triggerTraceString

A list of all the triggers run up until this point.

 

Each Event has its own custom properties that it exposes and are available to its child actions and can be used in the event conditions. See the page for each event for the details.

 

 

 

Workflow Actions can access information on all their ancestor actions and the Event that triggers that section of the Workflow. To do this choose which Event/Action will be the Source for the Condition, and then the appropriate list of Properties will be displayed for that Source. This allows the Condition to compare information from different Actions/Events.

 

Click to expand

 

All Actions have the following properties that can be used in conditions:

 

Example Properties

Notes

completedOkay

Whether the action Failed or Completed OK

errorMessage

Error message associated with failure

executedTime

The time the Action was executed.

stackTrace

The stack trace if failure occurs

triggerTraceString

A list of all the triggers run up until this point.

 

Each individual event and action may make additional information available for their child actions. See the documentation for each individual type of event or action for the details.

Workflows and Permissions

Some Events are triggered by users, and others are not. Database Events are usually triggered by users, although they can also be triggered by the system itself. In the case of a Database Event caused by a person doing something, then a user is "available". If this is a timed event, then there is no user available.

 

When an Action tries to create/update/delete something, there will be a fake/temporary user created. If there is a real user available, and that real user has Permission to perform the action, then it's that user whose permissions will apply. If there is no real user available, or the real user has no permission, then it's the fake user that will be used.

 

The fake user is endowed with the User Type and Roles assigned in the Action. These are defined on the Permissions tab in an Action.

 

However, there are limits to this. If the admin Role is added to an Action, then only users with the admin role will be able to modify the Workflow containing that action.

 

Also, if there is a real user available, then even if the fake user is the one whose permissions are used to validate the Workflow Action, it will be the real user that will be associated with the audit log entry. Audit log entries also now record the Workflow and Action that made a change, where performed by a Workflow.

 

Storing Temporary Data During Workflow Execution

If there is a requirement in a Workflow to store data temporarily, then you can create temporary variables with an action called Create Variables. You can create any of the variable types available inside the Bakery including their subtypes.

How To Check What Happened When a Workflow Runs

Go to Admin-->System Events and search for events around the time the Workflow should have run. Every time a Workflow Action or Workflow Event is run, there's an event created in System Events.

 

Each event and action can be configured so that it does not record a system event when it runs. In that case, there would be nothing in the system events to look at. Some events are, or may be, triggered frequently. If this is true in your case, then they should have system events disabled to avoid excessive data collection. For this reason, Anonymous Http Events have their system events disabled by default.