The events are defined in the Table Component, Configure Table screen, under the Events tab.

There is a similar Events tab available to Data Entry Forms. However Data Entry Forms are always linked to a particular Table, so it is usually best practise to configure the Table’s Events, rather than the Data Entry Form, primarily so you can keep all the business logic together.

The Events tab is also provided on the Login component and the Shopping Cart component.

Record Update Event

The Table’s Record Update Event is triggered whenever the record is updated, regardless of whether the update was made directly at the Table component itself, or on any of its linked Data Entry Forms. The Record Update Event configured on a Data Entry Form will only be triggered by an update made on that particular Data Entry Form.

When a form is submitted, the Record Update Event is queued to be triggered as soon as possible. This normally happens almost immediately, but ultimately is dependent on server loading and other scheduled activity.

To provide the user with the fastest experience they are taken to their post-submission page immediately, rather than waiting for the event to be executed (in particular some actions that interface with external services may take some time). This asynchronous processing of the event means that if the user is taken directly to a page which is displaying data that is dependent on actions taken by the event, they are unlikely to see the new data. This can be mitigated by taking them via a holding page, or querying the record until a status flag field indicates processing is complete.

Custom Events

In addition to the system-provided Record Update Event, you can add any number of Custom Record Events to a Table.

Right click on Events, choose New > Event > Custom Record Event, then name the event. Click Apply to save the event.

Custom Events can be thought of as Functions. You can call them from within other events, and pass values to them. Event executing can cascade, or even be set to recurse back on itself.

Objects within Events

An empty Event does nothing itself. Within an Event you can define any number of Conditions, Actions, and Delays.

• Conditions allow you to determine the circumstances when any following actions should be executed.
  Learn more about conditions.
   
• Actions are the payload, making things happening, for example changing field values, adding or deleting records, triggering the execution of other Events etc.
  Learn more about actions.
   
• Delays allow you to define when Actions should happen. Often you don’t want a delay, and need immediate execution, but sometime you want the system to wait, maybe days, before sending a reminder email. Delays can also be set to repeat, looping over a set of Actions on a regular basis.
  Learn more about delays.