The first block is called
When. It describes a source of events the rule should react to.
The following types of source items are supported in the UI:
- Modified Entity
- Incoming Web Hook
- Time Interval
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.
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.
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
startTimeUtcfield in a pipeline source block in JSON view. If there is no
startTimeUtcfield in a JSON rule config it is possible to create it manualy via JSON editor.
The format if the field is yyyy-MM-dd
- yyyy is a year
- MM is a month
- dd is a day of a month
Tis separator between date and time part
- HH is an hour of a day(values are
- mm is minutes in an hour
- ss is seconds in a minute
- SSSXXX is microseconds. They can be presented sometimes in some cases when
startTimeUtcwas generated by the system, like in this example
2023-02-10T12:56:47.6161099+00:00. No need to add them when
startTimeUtcis 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:00and a rule with this
+00:00is 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.
startTimeUtcis set to some date in the past the next run will be calculated according to a configured interval. If
startTimeUtcis 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) for predictability and unification.
Here is a couple of tricks which can help you in some spefic cases:
const now = new Date(); return now.getDate() == 1;
const now = new Date(); var max = new Date(now.getFullYear(), now.getMonth() + 1, 0).getDate(); return now.getDate() == max;
const now = new Date(); const day = now.getDay(); return day != 6 && day != 0;
- 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 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:
"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