You'll need actions in your application to process data. The triggers you set determine when an action is performed. The trigger is set to Manual by default, but there are more triggers that you can configure. These triggers have something to do with the record that is (or will be) processed.

In the graph below, you can see exactly when a trigger is triggered in the record lifecycle. There are roughly three types of records: new records, updated records, and deleted records.
​

Take note of how some triggers appear in multiple flows. The Before save flow, for example, is part of the New record and Update record flows. The trigger or callback list appears after you've chosen the model on which the action will be executed. Every action you create begins with a trigger.

The triggers are alphabetically ordered, both in the settings as in this article.
​Note: Some triggers prevent the use of background processing. When an action is set to a Before trigger, it must be immediately executed otherwise the database operation must be put on hold, which we won't do. Same goes for After destroy and After validation.

Background jobs

Background jobs have a maximum run/calculation time of 4 hours, if the job isn't finished within that time. The job will be executed and the action will be considered as failed.

Make sure your action is finished before that time by making the flow and steps as efficient as possible.

The calculation time for Background jobs will be reduced to a maximum of 1 hour in the future. Be prepared for this change and adapt in time!

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.
​Available for Background processing: Yes.

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.
​Note: You can't use the record's data in this action, because it has been deleted. If you would like to use the record's data, use Before destroy.
​Available for Background processing: No.

The action will be triggered after saving a record matches an existing record.

When to use? After match means that the application has done an insert or update operation into the database. An existing record is matched by the newly inserted data. Use this trigger if you would like to start a process after the record is matched. To let records match, use the Deduplicate setting on the model you're working with.
​Example: You are using a ticketing system for internal issues. After an existing issue (record) is matched (and potentially updated), you would like to inform the issue owner.
​Available for Background processing: Yes.

The action will be triggered after a new or an existing record is saved.

When to use? After 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 update a property with combined values of other properties.
​Available for Background processing: Yes.

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 (e.g. the issue assignee has changed the status into 'On hold' or 'In Progress') you would like to send the issue owner an update email.
​Available for Background processing: Yes.

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

When to use? Before create means that the application is going to do 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.
​Available for Background processing: No.

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

When to use? Before destroy means that the application is going to do 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. With 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.
​Available for Background processing: No.

This action will be triggered before saving a record matches an existing record.

When to use? Before match means that the application is going to do an insert or update operation into the database. An existing record is going to be matched by the newly inserted data. Use this trigger if you would like to start a process before the record is matched. To let records match, use the Deduplicate setting on the model you're working with.
​Example: You are using a ticketing system for internal issues. After an existing issue (record) is matched (and potentially updated), you would like to replace certain values.
​Available for Background processing: No.

This action will be triggered before a new or an existing record is saved.

When to use? Before save means the application is going to do 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.
​Available for Background processing: No.

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

When to use? Before update means that the application is going to do 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.
​Available for Background processing: No.

This action will be triggered before the validation is done on a new or existing record.

When to use? Before validation means the application is going to do 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:
​Available for Background processing: No.

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.
​Available for Background processing: No.

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:
​Available for Background processing: No.

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 a database operation. The manual trigger starts after a button on a form has been pressed. Setting an action to Manual also enables the action to be requested as a subaction in other actions.
​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 the green Run button. This will run the action in the foreground and tells you if the action was successful.
​Available for Background processing: Yes (recommended).

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.
​Available for Background processing: Yes, it's mandatory.

​Note: Scheduled actions will only be executed in production applications. In sandboxes the action won't be triggered by the cron job. For testing, you can press the green Run button on the action itself.