# Schedule rules

Scheduling an existing rule is done in 3 easy steps.

1.  In **Rules manager**. Create a new **Rule group** with **Type** set to **Only scheduled** or **Normal and scheduled**.

2.  Set the **Interval** to one of the predefined intervals or write a custom **Cron expression**.

3.  Move the rules that should be run on the group’s schedule to the group.

> **Note:**
> 
> The difference between the types **Only scheduled** and **Normal and scheduled** is that Normal and scheduled gets triggered on both the schedule and the rule’s triggers independent of each other. Only scheduled rules first gets triggered on schedule and then the system checks if the rule’s triggers are fulfilled before running the rule.

## Cron

If you decide to change the group to **Type** _Normal and scheduled_ or _Only scheduled_, choose the time **Interval** and optionally set up a **Cron expression**. Note that the latter setting changes depending on the **Interval** chosen. This is an optional setting to specify when to trigger the rule in a precise way. The syntax consists of 4 digits \[ \* \* \* ? \] to specify, respectively:

| Position: | \* | \* | \* | \* |
| --- | --- | --- | --- | --- |
| Represents: | Hour | Day of month | Month | Day of week |
| Allowed values: | 0-23 | 1-31 | 1-12 | 1-7 |
| Allowed special characthers: | , - \* | , - \* ? | , - \* | , - \* ? |

"\*" means “all values”, while "?" means "no specific value". The usage of "?" is crucial for day of month and day of week not to clash, one of them always has to be set to "no specific value".

**Example**

The default **Cron** for the **Hour** interval is `* * *` ? meaning that the rule will be triggered every hour, every day, every month, but without considering the day of the week.

**Example**

**Cron expression** set to `23 ? 1 2,6` makes the rules in the group run at 23:00, every tuesday and saturday in january.

## About schedule rules in general

**Rules are meant to be scheduled only if:**

-   Need to manage **expiration or due dates** that not always can be triggered by the user in an application form. As an example, let’s say that a user needs to receive an e-mail, notifying that shipments are about to be delivered, as a warning, a couple of days before arrival. But the user counts only with two fields in the application form: "ETA" (Estimated time of arrival) and "Arrival date", where the first one is entered only once and long before the warning e-mail is needed. Therefore, unless this rule is set as scheduled, the e-mail sending would not be possible with a one-time trigger event in the application form. See this [example](examples_of_rules.md#_send_e_mail_2_days_before_estimated_arrival) in more detail.

-   Need to re-assign existing records to a different record group in a massive way. In this case, by using a rule (with an [action](set_actions.md) of type **Set access rights on record**) in a _scheduled group_ (Hour interval), that you _inactivate immediately_ after editing the group of the desired records.

> **Note:**
> 
> Rules that contain the keywords **Changed**, **Updated**, **Inserted** and **Deleted** are not supported in scheduled rule groups.

> **Note:**
> 
> The usage of scheduled rules _may notably affect the performance of the application_, due to the evaluation periodically executed by the system _throughout the criteria of all records_ of the trigger table. In case they take a long time to be executed and overload the server resources, _the rules will be automatically stopped_, and the application administrators will be notified.
> 
> Use the [Rules monitor](rules_monitor.md) form to analyze scheduled rule execution.