---
title: "Restricting Communications by Time"
canonical: "https://docs.rubiconwater.com/space/CFGNC/2018672787/Restricting%20Communications%20by%20Time"
format: markdown
---
> Macro (toc)

You can restrict the times during which event-based messages can be sent by setting a blackout time for specific parts of the day. Messages sent during the blackout period can be sent in advance, or after the blackout, or events that occur during the blackout period can be ignored and no message sent. By default, any events that occur during the blackout are sent after the end of the blackout.

The blackout period will apply to all messages sent for the comm type, regardless of the delivery method.

> ℹ️ **Example**
> ℹ️ 
> ℹ️ You could stop messages from being sent late at night to avoid disturbing customers..

# Set a Blackout Period for a Comm Type

> ℹ️ **Note**
> ℹ️ 
> ℹ️ Blackout periods are configured in the [https://rubiconwater.atlassian.net/wiki/spaces/SMNC/pages/2000979029](https://rubiconwater.atlassian.net/wiki/spaces/SMNC/pages/2000979029), not in the Comm Types module.

**Step 1**

In the [https://rubiconwater.atlassian.net/wiki/spaces/SMNC/pages/2000979029](https://rubiconwater.atlassian.net/wiki/spaces/SMNC/pages/2000979029) click **Find Objects** to search for Comm Types.

**Step 2**

In the Find Objects screen, choose *Customer Communication Type* in the **Type** field and click **Find**.

**Step 3**

Select the comm type that you want to change and open the **Attributes** tab.

**Step 4**

Double-click on the *Blackout start time of days* attribute and enter the following details

| **Field** | **Description** |
| --- | --- |
| Effective | Date and time from which this blackout will be effective |
| Value | Time after midnight when the blackout will start (in seconds) |

**Step 5**

Repeat for the *Blackout end time of days* attribute to set the end of the blackout period.

**Step 6**

Click **Save** to save your changes.

# Sending messages before or after a blackout

You may want to send messages that would have been sent during the blackout, but to send them before or after the blackout. There are two controls for this behaviour:

- The *Poll in blackout; send after* **attribute** which is set on the Comm Type. It is set to *Yes* by default.
- The *Enable the check for next poll in blackout* **parameter** which is set at the system level. It is not set by default. It is only relevant for **Order Stop Alert** and **Order Start Alert** comm types.

This is how these controls work:

| **Poll in blackout attribute** | **Check next poll in blackout parameter** | **Result** |
| --- | --- | --- |
| Yes (default) | Not set (default), No | Messages for events that occur in the blackout are sent after the blackout as long as they have not expired by the time the blackout ends.<br>This is the default behaviour.<br>Note that this option is not useful for Order Start and Order Stop alerts because they would expire before the end of the blackout period. |
| No | Not set, No | Events in the blackout are ignored and no messages are sent. |
| Yes, No | Yes | Messages for events that will occur in the blackout are sent before the blackout.<br>This option is used for **Order Start** and **Order Stop** alerts because these message types would expire during the blackout period and no message would be sent even if the **Poll in blackout** attribute was set to *Yes*.<br>However, don't set both options to *Yes* for other message types or you will send duplicate messages (that is, before AND after the blackout). |

---