DocsDiscussionAPI ReferenceBlog

Sources

Suggest Edits

The first block is called When. It describes a source of events the rule should react to.

363

The following types of source items are supported in the UI:

  • Modified Entity
  • Incoming Web Hook
  • Time Interval
  • Other

Modified Entity Source

If a user chooses the Modified Entity source, then it’s required to specify an entity type and a type of modification happened to entity.
In case when selected modification types include Updated, modified fields should also be selected.
The rule will be executed only if any of the selected fields are modified.

795

Incoming Web Hook source

If a user chooses the Incoming Web Hook source, then a new Incoming Web Hook must be created to proceed.

When creating a new web hook, the user can choose a service it will be used for. This information is used to build suggestions that simplify configuring of next blocks of the rule pipeline. For now, predefined suggestions are supported for GitHub and GitLab.

It is possible to integrate with any tool that supports outgoing web hooks. Select "Other" and click the "Create new Incoming Web Hook" button in order to generate an URL where web hooks should be sent from the external tool.

Please check the following article, where it's described how to add web hooks to the most popular tools.

In existent web hook, user can always reset a service the web hook is used for. This will only affect suggestions that are shown in the rule configuration. In case when Other option is selected, suggestions are cleared. But, as soon as the next request come to the hook's endpoint, new suggestions will be generated based on the data came in the request.

Time Interval source

A Time-Based Automation Rule should have a time interval specified. These Rules allow to perform recurring actions, such as create a set of Tasks every week, or get notified about upcoming planned dates for User Story, and so on.

📘

The time interval can be between 15 minutes and 90 days.

📘

Editing start time of a rule via JSON view

It is possible to set/edit starting trigger time of a time based rule in startTimeUtc field in a pipeline source block in JSON view. If there is no startTimeUtc field in a JSON rule config it is possible to create it manualy via JSON editor.

The format if the field is yyyy-MM-ddTHH:mm:ss.SSSXXX+00:00 , where:

  • yyyy is a year
  • MM is a month
  • dd is a day of a month
  • T is separator between date and time part
  • HH is an hour of a day(values are 00-23)
  • mm is minutes in an hour
  • ss is seconds in a minute
  • SSSXXX is microseconds. They can be presented sometimes in some cases when startTimeUtc was generated by the system, like in this example 2023-02-10T12:56:47.6161099+00:00. No need to add them when startTimeUtc is added manualy, and they can be freely removed from system generated startTimeUtc. There is no difference in trigger time for a rule with this 2023-02-10T12:56:47.6161099+00:00 and a rule with this 2023-02-10T12:56:47+00:00 value for startTimeUtc
  • +00:00 is UTC timezone postfix

It is important to note that it is startTime . So it will set daily run time for rules with interval multiple of one day, like 1,2... days or 24, 48, 72... hours. Otherwise naturally next daily run time will changed after every run. For example, it is impossible to have same daily run time every day for a rule with 25 hour interval.

If startTimeUtc is set to some date in the past the next run will be calculated according to a configured interval. If startTimeUtc is set to some future date the next run of the rule will be in future at this particular date and time and next runs will be calculated according to a configured interval.

If only time that is matters it is possible to set only time part 15:30:00+00:00. In this case the date part will be taken from the current date.

It is recommended to keep timezone postfix+00:00 as UTC(+00:00) for predictability and unification.

Here is a couple of tricks which can help you in some spefic cases:

  1. If you need to run the rule at the first day of the month, you can set the rule to be run every day and use the following Javascript filter:
const now = new Date();
return now.getDate() == 1;
  1. If we need to run a rule on the last day of the month, you can set the rule to be run every day and use the following Javascript filter: 
const now = new Date();
var max = new Date(now.getFullYear(), now.getMonth() + 1, 0).getDate();
return now.getDate() == max;
  1. If you need to run the rule every working day, you can set the rule to be run every day and use the following Javascript filter:
const now = new Date();
const day = now.getDay();
return day != 6 && day != 0;
  1. If you need check when the rule was previously executed in order to compare this to some specific date you can use args.PreviousFireTime:
const previousTime = args.PreviousFireTime;

🚧

args.PreviousFireTime will return some value only in case the rule is scheduled.
If the rule is triggered manually it will return null

Named Trigger

Named triggers are used to reuse the automation rule code.

"Activate Named Trigger" option in the "When" dropdown, then use JSON to define the named trigger:

JavaScript

{
"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)

Updated 13 days ago