You are reading the documentation for an outdated Corteza release. 2024.9 is the latest stable Corteza release.

Automation Trigger Anatomy

To better understand the power of automation triggers and their definition, we define and describe the anatomy of automation triggers.

Automation triggers are constructed with the following methods:

t.on

Defines the event type, such as 'manual', 'request' (see [ext-resevt]).

t.for

Defines the resource type, such as 'compose:record' (see [ext-resevt]),

t.where

Defines the constraints that must match in order for the automation script to be executed (eg. t.where('module', 'Lead')). Refer to Constraints for details,

t.before

Defines that the automation script is executed before a specific operation occurs,

t.after

Defines that the automation script is executed after a specific operation occurs,

t.at

Defines that the automation script is executed at a specific time,

t.every

Defines the interval in which the automation script is executed,

t.uiProp

Defines the visual representation of the manual automation trigger, such as its color and label.

Trigger and iterator are not compatible; you can only use one or the other within the same automation script.

Triggers will be evaluated in an isolated context outside of the actual automation script file. This prevents use of any constants or other symbols defiled outside of the trigger.

For example, the following trigger will cause:

const modName = 'Contact'
export default {
  triggers ({ on }) {
    return on('manual')
      .for(modName)
  },
  exec (args, ctx) {...}
}

When defining the automation script, you can use object destructuring to remove a few bits of code.

triggers (t) {
    return [ t.on(...)... ]
}

// can be replaced by

triggers ({ on }) { // any of the above mentioned methods
    return [ on(...)... ]
}

If the automation script contains just a single trigger, you can omit the array and just return the one.

triggers ({ on }) {
    return [ on(...)... ]
}

// can be replaced by

triggers ({ on }) {
    return on(...)...
}

Constraints

A constraint consists of 3 components:

  1. resource attribute name (see [ext-constraintResources]),

  2. operation,

  3. value.

Constraint operations

  • Equal: check for equality between the two values. Available operators:

    • eq

    • =

    • ==

    • ===

Equality check is default operator. When using only 2 parameters for constraint, "equal" operator is used

  • Not equal: negated check for equality between the two values. Available operators:

    • not eq

    • ne

    • !=

    • !==

  • Like: check for string equality, with support for wildcards. Available operators:

    • like

  • Not like: negated check for string equality, with support for wildcards. Available operators:

    • not like

Available wildcards:

  • one or more characters: %, *,

  • one character: _, ?.

  • Match: check for string equality, defined as a regular expression. Available operators:

    • ~

  • Not match: negated check for string equality, defined as a regular expression. Available operators:

    • !~