Reusable automation rules via Named Triggers

Named Triggers in the automation rule are used for reusing a block of code. The advantage of this feature are:

  1. Parameters can be defined in a single rule and reused in many triggers.
  2. A core part of the rule can be extracted into a reusable function/block, leaving small rules for triggers.

Create a new rule, and select the "Activate Named Trigger" option in the "When" dropdown, then use JSON to define the named trigger:

{
  "type": "source:uniqueName",
  "name": "tp test unique name 1"
}

source:uniqueName is required, and the name can be any unique name for this trigger that you'll use later to activate it (pretty much like webhook URL, but without HTTP-related issues)

Add any action to that rule, most likely JavaScript. You can access the data passed to the trigger via theargs.data
Entire rule JSON for reference

{
  "pipeline": [
    {
      "name": "tp test unique name 1",
      "type": "source:uniqueName"
    },
    {
      "type": "action:JavaScript",
      "script": "console.log(args.data);"
    }
  ]
}

Add another rule which activates that named trigger. Instead of sending an HTTP request to webhooks, you return a new command indicating which named trigger you'd like to fire, for example:

return {
  command: 'ActivateNamedTrigger',
  payload: {
    name: 'tp test unique name 1',
    // Optional. This will be passed to `args.payload` of the named trigger
    data: args.Current
  }
}

Example rule reacting to the creation of UserStory.

{
  "pipeline": [
    {
      "type": "source:targetprocess:EntityChanged",
      "entityTypes": [
        "UserStory"
      ],
      "modifications": {
        "created": true,
        "deleted": false,
        "updated": false
      }
    },
    {
      "type": "action:JavaScript",
      "script": "return {\n  command: 'ActivateNamedTrigger',\n  payload: {\n    name: 'tp test unique name 1',\n    data: args.Current\n  }\n}"
    }
  ]
}

📘

Nested named triggers

Activating a named trigger A from a rule reacting to some other named trigger B is supported. However, the repeated activation is not supported, neither directly (a rule reacts to a trigger A and activates a trigger A) nor transitively (a rule reacts to a trigger A, activates trigger B, which in turn activates A again).

Here is an example rule that uses theargs.data information and creates a Task when UserStory is Triggered.

{
  "pipeline": [
    {
      "type": "source:targetprocess:EntityChanged",
      "entityTypes": [
        "UserStory"
      ],
      "modifications": {
        "created": true,
        "deleted": false,
        "updated": false
      }
    },
    {
      "type": "action:JavaScript",
      "script": "return {\n  command: 'ActivateNamedTrigger',\n  payload: {\n    name: 'tp',\n    // Optional. This will be passed to `args.payload` of the named trigger\n    data: {\n      id:args.Current.Id,\n      name1: args.Current.Name,\n      projectname: args.Current.Project.Name,\n      projectid:args.Current.Project.Id\n    }\n  }\n}"
    }
  ]
}
{
  "pipeline": [
    {
      "name": "tp",
      "type": "source:uniqueName"
    },
    {
      "type": "action:JavaScript",
      "script": "{\r\n  console.log(args.data);\r\n  return {\r\n    command: \"targetprocess:CreateResource\",\r\n    payload: {\r\n      resourceType: \"Task\",\r\n      fields: {\r\n        Project: { Id: args.data.projectid },\r\n        UserStory: {Id:args.data.id},\r\n        Name: \"New Task\"+args.data.name1,\r\n      }\r\n    }\r\n  }\r\n}"
    }
  ]
}