Timer
Actions of this type are launched cyclically for defined instances. They allow you to specify the starting time and repetition cycle. Several actions of various types can be associated with one timer. The way of calculating the times of consecutive executions depends on individual parameter settings.
Please note that such actions can be defined only within the steps as they have to be associated with a particular instance.
Configuration
You can access the configuration of the Timer actions by adding such an action from the step or path configuration window (the Actions tab → the Actions list panel → Timer).
1. Basic information
Timer identification data: Name, ID, and Description. If the ID value is less than “0”, the timer has not yet been stored in the database.
2. Operation mode
The Only action execution mode is a standard timer operation mode. It causes the execution of actions associated with it in intervals defined in its settings.
The Path transition after action call mode causes the instance to move along a path in intervals defined in the timer settings.
3. First activation
The parameter enables you to define the date and conditions under which the timer will be activated for the first time.
Start date
The parameter determines whether the first activation is to occur immediately after step entry or subject to the additional configuration related to the timer date specification (reference to the Date and time form field on the workflow instance, offset from the form field date or step entry date).
For a timer whose first activation occurs immediately, the specific configuration parameters: Only nighttime, Executed at specific hours, and Ignore days off are not available. These will only be applied on subsequent timer runs.
Offset
The value of the offset of timer's first activation date in relation to the Start date, expressed in days. The offset value is an integer: positive, negative or equal to “0”. Based on it, the timer start date will be postponed accordingly.
Interval
The frequency of timer repetitions (including its first start). You can set a value greater than “0” and indicate minute, hour, day, week or month as the unit.
Launch day
Should the timer repetition interval be expressed in weeks or months, this field allows you to specify the exact day of the week or month that the timer will be launched.
4. Repeat in cycles
The field determines whether the timer will be run once or in cycles. The default setting is unchecked.
Number of executions
The total number of timer executions, including the first run. The default value is set to "5" if Finite number is selected from the list. Once the set number of executions is reached, the timer will no longer run.
If the Infinite number is selected, the timer will continue to run in cycles until the instance does not exit the step.
5. Insert condition
The field enables you to enter an SQL query that checks if a timer can be inserted. If the query returns "1" or "TRUE", the timer will be associated with an instance. Otherwise, the timer will be ignored.
6. Only nighttime
Specifies if timers are to be run only at nighttime.
7. Executed at specific hours
Defines hours when a timer is to be activated. Enter the desired "from-to" range of hours.
8. Ignore days off
When checked, it will cause the specified days to be omitted when calculating activation times for actions triggered by timer.
Ignore weekends
Actions will not be activated on Saturdays and Sundays. Additionally, Saturdays and Sundays will be omitted when calculating the date and time of the next activation cycle, i.e. the week will be treated as if it had 5 days.
Ignore all non-working days
Actions will not be activated on non-working days, which are defined in the working days calendar. Additionally, the defined days will be omitted when calculating the date and time of the next activation cycle.
9. Path transition on execution error
A path transition occurs when a timer action returns an error. This includes errors (other than validation errors) from path transitions after executing a timer action, or saving an instance after executing a timer action in Only action execution mode. If any action on the selected path returns "FALSE" or an error, the path transition will not occur.
10. Path transition on validation error
Path transition occurs when a timer action returns "FALSE" instead of an error. This does not apply to validation errors (not including execution errors) from path transitions after executing a timer action, or saving an instance after executing a timer action in Only action execution mode. An instance will not follow the selected path if any action on the selected path returns "FALSE" or an error.
11. Acceptable number of consecutive errors
The number of consecutive erroneous timer executions that will stop the execution of the actions associated with it. The default value of the parameter is “5”.
12. Number of minutes to retry after error
Number of minutes after which the timer will retry execution if an error occurs. The default value of the parameter is “10”.
13. Test
The button allows you to verify the operation of the timer. After pressing it, the Planned timer executions window is displayed.
By specifying the step entry date and time, you can calculate when the timer will be executed based on the configured settings.
If a Date and time form field is used in the timer definition, it will be displayed in the window and taken into account for recalculation of scheduled timer executions.
The number of items displayed in the window is up to 10, with smaller values corresponding to the defined Number of executions.
Timer start times calculation
Date of first timer activation
The date from which the timer calculation begins is established in accordance with the following conditions (the compliance with the conditions is checked in the specified sequence):
- if the timer is activated on a specific day – the first activation date corresponds with the first planned activation (calculated on the basis of timer definition) that occurs after the start date and the current date,
- if the start date is fetched from a form field – the first activation date is the date obtained from that form field. If that date is in the past, a timer activation occurs immediately. A timer activation occurs on the cycle start,
- if an offset had been configured for a timer – the first activation is the obtained date with added offset time,
- if the beginning date is the date of entering the step and there is no defined offset – the first activation date corresponds with the first planned activation after the cycle start calculated on the basis of defined intervals. A timer is not activated on the cycle start.
Start from the date specified in a form field:*
Start date: May 1st; Current date: May 8th; Interval 5 days;
Planned timer dates: May 1st, 11th, and 16th.
*The 1st of May is the first planned date, in reality however, the timer will activate on the 8th (right after its creation)
Start date is the date of entering the step:
Start date: May 1st; Current date: May 1st; Interval: 5 days;
Timer dates: May 6th, 11th, and 16th.
Start date: May 1st; Current date: May 8th; Interval: 5 days;
Timer dates: May 11th, 16th, and 21st.
Ignore weekends
- Type: minute, hour, day A 5-day week is taken into account. If the activation date falls on a weekend, the activation will take place on the following Monday.
Start from the date specified in a form field:
Start date: May 1st (Saturday); Current Date: May 3rd (Monday); Interval: 5 days;
Ignore weekends: on
Timer dates: May 3rd (Monday), 10th (Monday), 24th (Monday)
Start date is the date of entering the step:
Start date: May 1st (Saturday); Current date: May 3rd (Monday); Interval: 5 days;
Ignore weekends: on
Timer dates: May 10th (Monday), 17th (Monday), 24th (Monday)
Start date: May 1st (Saturday); Current date: May 1st; Interval: 5 days;
Ignore weekends: on
Timer dates: May 3rd (Monday), 10th, 17th
Start date: February 1st (Monday); Current date: February 1st; Interval: 7 days;
Ignore weekends: on
Timer dates: February 10th (Wednesday), 19th (Friday), March 2nd (Tuesday), 11th (Thursday), 22 (Monday)
- Type: week, month If the activation date for a timer falls on a weekend, the activation will take place on the following Monday.
Start date: May 1st (Saturday); Current date: May 5th (Wednesday); Interval: 1 week;
Ignore weekends: on
Timer dates: May 10th (Monday), 17th (Monday), 24th (Monday)
Start date: February 1st (Monday); Current date: February 1st (Monday); Interval: 1 week;
Ignore weekends: on
Timer dates: February 8th (Monday), 15th (Monday), 22nd (Monday)
Setting a specific day of a weekly or monthly cycle
The first activation occurs on the nearest specified type of day (either a day of the week or a day of the month) that follows the start date.
Start date: May 1st (Saturday); Current date: May 1st (Saturday); Interval: 1 week;
Day in cycle: Monday
Timer dates: May 3rd (Monday) , 10th (Monday) , 17th (Monday)
Start date: May 1st (Saturday); Current date: May 3rd (Monday); Interval: 1 week;
Day in cycle: Monday
Timer dates: May 10th (Monday) , 17th (Monday) , 24th (Monday)
Start date: January 1st 2010; Current date: January 1st 2010; Interval: 1 month;
Day in cycle: 31
Timer dates: January 31st (Sunday) , February 28th (Sunday), March 31st (Wednesday)
If you select day in a cycle and check the Ignore days off checkbox, the date of the next timer activation will be the first day that do not fall on a weekend.
Start date: January 1st 2010; Current date: January 1st 2010; Interval: 1 month;
Day in cycle: 31
Ignore weekends: on
Timer dates: February 1st (Monday) , March 1st (Monday), 31st (Wednesday)
Start Date: May 1st (Saturday); Current Date: May 1st (Saturday); Interval: 1 week;
Day in cycle: Sunday
Ignoring weekends: on
Timer dates: May 3rd (Monday) , 10th (Monday) , 17th (Monday)
Activation with an offset
When activation has an offset, the system adds/subtracts a specified number of days to/from the start / form field date.
Start date: March 1st 2010; Current date: March 1st 2010; Interval: 1 Month;
Offset: 7 days
Timer dates: March 8th, April 8th, May 8th
If the Ignore days off checkbox had been selected, only business/working days will be taken into account in the offset time.
Start date: March 1st 2010; Current date: March 1st 2010; Interval: 1 month;
Offset: 7 days;
Ignore weekends: on
Timer dates: March 10th, April 12th, May 10th
Activation at a specific hour
- Type: minute, hour A day is treated as a time frame defined by activation hours. If an activation date falls outside these activation hours (the time frame of a given day), the remaining time will be added to the next day.
Activation hours: 10:00 AM - 3:00 PM, start on the date specified in a form field:
Start date: May 1st 2010 8:30 AM; Current date: May 1st May 2010 9:00 AM; Interval: 3 hours
Timer dates: May 1st 10:00 AM, May 1st 1:00 PM; May 2nd 11:00 AM
Activation hours: 10:00 AM - 3:00 PM, start on step entry:
Start date: May 1st 2010 8:30 AM; Current date: May 1st 2010 9:00 AM; Interval: 3 hours
Timer dates: May 1st 1:00 PM, May 2nd 11:00 AM; May 2nd 2:00 PM
- Type: week, month
If the activation date falls outside activation hours, the cycle is calculated from the start nearest activation time frame.
Activation hours: 10:00 AM - 3:00 PM, start on the date specified in a form field:
Start date: May 1st 2010 4:00 PM; Current date: May 1st 2010 4:00 PM; Interval: 2 days
Timer dates: May 2nd 10:00 AM, May 4th 10:00 AM; May 6th 10:00 AM
Activation hours: 10:00 AM - 3:00 PM, start on step entry:
Start date: May 1st 2010 4:00 PM; Current date: May 1st 2010 4:00 PM; Interval: 2 days
Timer dates: May 4th 10:00 AM, 6th 10:00 AM; 8th 10:00 AM
Handling validation errors / timer action execution errors
- Validation error from timer action execution results in:
- going through the path for the validation error (if Path transition on validation error is checked),
- determining the next run according to the algorithm (as if the timer had been executed correctly, increasing the value of the counter of correct executions).
- Validation error from the path transition after executing the timer action results in:
- going through the path for the validation error (if Path transition on validation error is checked),
- determining the next run according to the algorithm (as if the timer had been executed correctly, increasing the value of the counter of correct executions).
- Timer action execution error results in:
- going through the path for the execution error (if Path transition on execution error is checked),
- determining the next execution in the number of minutes specified by the Number of minutes to retry after error parameter.
- Execution error from the path transition after executing the timer action results in:
- going through the path for the execution error (if Path transition on execution error is checked),
- determining the next execution in the number of minutes specified by the Number of minutes to retry after error parameter.