Skip to main content


A trigger is a type of function that runs in response to a data mutation event (i.e, while creating, updating or deleting an object). This allows for important actions to run as callbacks to your data commits, without cluttering up client apps with web requests.


There are two type qualifiers for triggers based on whether they run before or after the data is modified: trigger.before and trigger.after. The operation parameter defines what data type and event the trigger should listen to. For example, if we want to execute it after a User has been created we should specify User.create. Possible values for the data event are create, update and delete.

# Declare custom triggers like so.
code: src/triggerBefore.ts
type: trigger.before
operation: User.create

operation Options

When defining an operation, use: <TableName>.(create|update|delete)


This type of trigger is executed before the data is written to the database. It allows you to validate or modify the data before saving it in the database.

module.exports = event => {
const { password, passwordConfirm } =;

if (password != passwordConfirm) {
// Throwing an error will cancel the operation and data will not be inserted
throw new Error('Passwords don\'t match');

// You can modify what goes into the database
return {
data: {,
status: 'confirmed'


This type of trigger is executed after the data has been successfully saved in the database. It can be used to do any post-processing or to enrich the returned data. For example, after creating a new calendar event you might want to send an email notification alerting users they were invited.

const sender = require('email-service');

module.exports = async event => {
const { invitees } =;

let sent = false;
try {
await sender.sendInvites(invitees);
sent = true;
} catch(e) {
console.error('Error sending invites: ', e);

// You can modify the returned response
return {
data: {,

Trigger Arguments

Alike the standard custom function arguments, a trigger.after type function receives the output of a mutation in the property. However, sometimes parameters that were originally passed in the mutation are needed. Therefore, the event object is enriched to have a event.originalData property which maintains the original input object.

event.originalObject also contains the version of the object before the mutation was applied to it. This is useful when you need to compare objects before and after the mutation to find out what fields changed.

// Data returned
"data": {...},
// Data sent
"originalData": {...},
// Original data record
"originalObject": {...} // or null,
// Request headers
"headers": {...}

To learn more about the arguments that are passed to triggers, review the custom function arguments docs.

Trigger Response

The value returned by a trigger is allowed two properties: data and errors.

return {
data: {
errors: [{
message: "Error message",
code: "error_code"


It is not advisable to use triggers in order to create other entities or change the current and others. First of all, the functionality of triggers is used to validate the input parameters in the trigger.before or to send a notification in the trigger.after.

on this page
Was this article useful?
89% of our users said this content was useful.