A Database Workflow Event is triggered in response to a change in the data stored in the database. That means it represents data being created, updated or deleted.

Event Properties

As well as the standard properties that can be set on all events, the following properties can be set on this type of event:

 

Property

Description

Target Type

The type of biskits whose creation, deletion or update triggers this event.

Create Events

true if an this event should be triggered by the creation of a biskit, and false if we should ignore biskit creation events.

Update Events

true if an this event should be triggered by the update of a biskit, and false if we should ignore biskit update events.

Delete Events

true if an this event should be triggered by the deletion of a biskit, and false if we should ignore biskit deletion events.

Vetoable Events

When a database event occurs, you sometimes want to run inside the database transaction so that you can modify the data before it is saved or so that you can prevent (or veto) the database change. But you sometimes would prefer to be outside the database transaction so that the event is triggered only after the database change has completely finished. Set this optionto true if we should run inside the database transaction and so have the option of preventing the transaction from completing, and false if we should run after the transaction has completed.

 

Vetoable Events

The option for running with vetoable events can be a bit confusing. It's all a question of whether you run inside the database transaction or after it has completed. Let's explain this with some examples.

 

Suppose you create a system that records somebody purchasing something, and you use a workflow to keep track of how much money they have. Then a biskit might be created when a purchase is made. But suppose the workflow discovers that the user does not have enough money to buy the goods. Then the workflow should veto the change by calling a Veto Workflow Action. For this to work, the event must have been set to work with vetoable events so that it runs inside the database transaction. Otherwise, the transaction would complete before you checked whether they had sufficient money.

 

Now suppose you want to send an confirmation email whenever somebody makes a purchase. If there are multiple workflows that do things with or to the purchase biskit, you might find that you send the email and then something else vetoes the purchase. That would mean the email gives misleading information. So you should make sure the database event that triggers the email is done without vetoable events because that means it will only be called after the change has been finalised.

 

Properties Available for Child Actions To Use

The following properties are available for use in any child or descendant action:

 

Properties

Notes

new

The new value of the biskit after the change. old and new are identical for a create and a delete.

old

The old value of the biskit before the change.

AuditLog

Information stored in the AuditLog for this change. This records information about who made the change, when, and what the biskit was like after the change.

UserMakingTheChange

Indicates which user made the change.

Crud

Property storing the type of change Create, Update, Delete.