Action Reference


To process data in your application, you’ll need actions. Actions are workflows (logic) in the application. An action is a sequence of events that happen when the action is triggered. Every action contains a model (with data) which defines the roadmap of the action events. An action always starts because of the trigger. Besides automatic triggers, you can also set a manual trigger by adding buttons. 

General action settings

Sample

The options you can set when creating a new action are:

Enabled
Allows the action to be enabled or disabled.
Description
Allows you to describe the action.
Model
Select the model on which the action has to be executed.
Triggers
(visible when a Model is selected) Declares the trigger/callback which initiates the action.
Schedule
(visible when a Model is selected) Allows you to repeat the action automatically according to a schedule in cronjob format.
Batch
(visible when a Model is selected) Allows you to select records from a grid (via a checkbox) on which you want to perform the action. There’ll be an extra action button at the bottom of your view.
Preserve collection
(visible when Batch is selected) Transforms the batch from a ‘for each selected options' in the grid, execute the action to an ‘execute action once for total selected collection’. Explanation: if the action consists of a ‘send mail’ task, you should check ‘Preserve collection’. This will make sure to send one mail with the action outcome of every selected options. Without this option, every checked option will result in a different mail.
Background
Allows you to select whether the action will be executed on the background or on the foreground.
Note: Executing an action in the background isn't possible when one of the 'Before' action triggers is chosen. As a background action may have to wait a few seconds to be executed, a record can't wait for this to be completed as the record needs to be created, updated or deleted.
Show notification
(visible when Background is selected) When the action is executed in the background and you want to receive information when executing you can choose between: No, Yes, and Yes:and show popup when ready.
Execute
(visible when Background is selected) When the action is executed in the background you can select the execution time of that certain action with other actions.
- Max one at a time means: your application executes one action at a time. When several actions are planned, the actions executes them one by one. This can be important when actions are dependent on each other.
- Max one per record at a time means: when repeatedly clicked on the action button within a record, it will wait until the first action was carried out before the next begins. This is important when actions within a record dependent on each other.
- Without limits means: the actions can be executed at the same time from different records or within a record. They are not depending on each other.
Help text
Allows you to give the action a short help text for other developers, so they can read the help text and immediately knows what de action exactly does.
Debug action
Allows the possibility of looking back at every step of the action in the logs.
Log execution
Allows the possibility of looking back at who executed the action at what time.
Variables
Allows you to create variables which the action can fill. Input variable needs to be filled in by a user such as in a form, general variables are variables declared by an expression.


Go fullscreen

You'll find a fullscreen button in the top right of your action. This will make it easyer to oversee your big actions.




Action triggers

Sample

Sample

After you have selected the model on which the action is executed, the trigger or callback list appears. The trigger is the start of EVERY action (read: process or workflow) you create. All triggers are based on the basic operations on model objects: CRUD (create, read, update, and delete).



After create

The action will be triggered after a NEW record is created.

When to use? After create means that the application has done an insert operation into the database. A 'new' record is created and exists! Use this trigger if you would like to start a process which is based on the inserted new record. Example: you are using a ticketing system for internal issues. After a new issue (record) is created, you would like to send a confirmation email to the issue owner. 



After destroy

The action will be triggered after a record is deleted. 

When to use? After destroy means that the application has done a delete operation into the database. An ‘existing’ record is deleted. Use this trigger if you would like to start a process after the record is deleted. Example: you are using a ticketing system for internal issues. After an existing issue (record) is deleted, you would like to inform the issue owner.



After match

The action will be triggered after a NEW record matches an EXISTING record.



After save

The action will be triggered after a NEW or an EXISTING record is saved. 

When to use? Ater save means that the application has done an insert OR update operation into the database and saved the record. Whether you have created a ‘new’ or updated an ‘existing’ record, the after save trigger starts. Use this trigger if you would like to start a process which applies to new AND existing records. This trigger applies to both (create and update) operations. Example: you are using a ticketing system for internal issues. After a new or existing issue record is saved, you would like to give that certain issue record a priority which is based on a couple input fields as issue type for example.  



After update

The action will be triggered after an EXISTING record is updated (changed values).

When to use? After update means that the application has done an update operation into the database. An ‘existing’ record is changed (one or more property values). Use this trigger if you would like to start a process which is based on the updated record. Example: you are using a ticketing system for internal issues. After an existing issue (record) is updated (the issue assignee has changed the status into 'review' or 'testing') you would like to send the issue owner an update email. 



Before create

The action will be triggered before a NEW record is created.

When to use? Before create means that the application will do (has not done yet) an insert operation into the database. A ‘new’ record will be created. Use this trigger if you would like to start a process before a new record is created. Example: you are using a ticketing system for internal issues. Before a new issue record is created you can assign the new issue record to the owner who made this issue. Before the new issue record is inserted in the database, it is assigned to its owner. 



Before destroy

The action will be triggered before an EXISTING record is deleted.

When to use? Before destroy means that the application will do (has not done yet) a delete operation into the database. An ‘existing’ record will be deleted. Use this trigger if you would like to start a process before the existing record is deleted. Example: you are using a ticketing system for internal issues. Before an existing issue record is deleted, you would like to inform the issue owner that the issue is deleted. Before delete, you are still able to collect data from the record that will be deleted when the operation is done. This is on the contrary to After delete. You will not be able to use data from the record that is deleted. The record is not existing anymore at that point. 



Before match

This action will be triggered before a NEW record is saved while it matches an EXISTING record.



Before save

This action will be triggered before a NEW or an EXISTING record is saved.

When to use? Before save means the application will do (has not done yet) an insert OR update operation into the database and saves the record. Whether you have created a ‘new’ or updated an ‘existing’ record, the before save trigger starts. Use this trigger if you would like to start a process which applies to new AND existing records. This trigger applies to both (create and update) operations. Example: you are using a ticketing system for internal issues. All new and updated issue records must contain a status ‘open’ until the issue is closed. 



Before update

This action will be triggered before an EXISTING record is updated. 

When to use? Before update means that the application will do (has not done yet) an update operation into the database. An ‘existing’ record will be updated. Use this trigger if you would like to start a process before an existing record is updated. Example: you are using a ticketing system for internal issues. For every issue, you are logging the issue history. Before an existing issue record is updated, you want to store the current data into a history Model.

NOTE: model actions which triggers ‘before update’ can’t have update EVENTS in the action's workflow. Why? It causes an infinite loop because you cannot update properties (with events) on a record which triggers before the update operation itself. Which events do I have to use? Use the ‘assign event’ instead of ‘update’. Assign event does not cause an infinite loop.



Before validation

This action will be triggered before the validation is done on a NEW or an EXISTING record.

When to use? Before validation means the application will do (has not done yet) an insert OR update operation into the database and saves the record. Before the insert or update operation is executed, a validation operation starts. Whether you have created a ‘new’ or changed an ‘existing’ record, the before validation trigger starts. Use this trigger if you would like to start a process before the validation on new AND existing records. Example:



Before validation on create

This action will be triggered before the validation is done on a NEW record.

When to use? Before validation on create means the application will do (has not done yet) an insert operation into the database. A new record will be created. Before inserting the new record a validation operation starts. Use this trigger if you would like to start a process before the validation on the new record starts. Example: you are using a ticketing system for internal issues. The issue record contains a required date property calls ‘planned date’. Issue owners create new issues but are not able to fill in the planned date. However, the planned date is a required property of the new issue record. We have to start a process that triggers on before validation on create so we can assign the planned date two weeks ahead. Before the validation operation starts, the planned date property has a value and will pass the validation successfully. 



Before validation on update

This action will be triggered before the validation is done on an EXISTING record

When to use? Before validation on update means the application will do (has not done yet) an update operation into the database. An existing record will be updated. Before updating the existing record a validation operation starts. Use this trigger if you would like to start a process before the validation on the existing record starts. Example: 



Mail event

This action will be triggered when an email is sent from the application. This is not the same as the send mail action event!



Manual

This action will be triggered manually, commonly by pressing a button on the view form of a record.

When to use? When you want to start a process that is not followed by creating a new record or updating or deleting an existing record. The manual trigger starts after a button on a form has been pressed. Example: you want to subscribe a contact person from your CRM to your MailChimp account. The person will be added to MailChimp by clicking the button on the contact form. Another example: you would like to change the order status or issue status. You can trigger this process manually by placing a button on the order or issue form. While developing: You can manually run an action while building to test it. You achieve this by clicking edit on your action and then run manually. This will run the action in the foreground and tells you if the action was succesfull. 



Scheduled

This action will be triggered on scheduled moments which you can set yourself. 

When to use: when you want to start a process which must be executed automatically according to a scheduled time format. This time format can be set by yourself according to the cronjob format. Example: every day at five o’clock in the afternoon the application sends an email with the daily sales results. Or every day at midnight the scheduled action collects data from other applications or systems by a http request action event which contains a predefined web service. Or every day at nine o’clock in the morning the scheduled action loops through all your tasks and mails the current overdue tasks. 

related reference: Now you know what te general action settings are and what kind of triggers there are, you are ready to see the Action Event Reference!


Didn’t find what you want?Ask your question on the forum!