# Recurring Notifications

# Recurring Notifications

<h2 id="bkmrk-overview">Purpose and when to use this record</h2>

Schedule a repeated alert for selected recipients with a weekly, monthly, quarterly, or annual cadence.

## At a glance

- **Identify it by:** **Label**, **Body**, **Notification Link**, and **Alert Level**.

- **Check its business context:** **Owner**.

- **Why care:** Setup changes can alter navigation, alerts, and authorization for many users. Test the effect with the intended role or device before broad use.

- **Why care:** Availability and publication flags affect future use without erasing history. Prefer disabling an obsolete setup record when existing transactions still refer to it.

## Before you begin

You need the Brisk permission for the action you are taking on recurring notifications. If a Create, Edit, or Delete control is absent, do not work around it with another user’s account; ask an administrator to review your role.

<h2 id="bkmrk-create">Create a recurring notification</h2>

<figure class="brisk-doc-media"><img src="https://help.brisksystems.us/uploads/images/gallery/2026-08/article-modelsetuprecurringnotification-create-recurring-notification-create.png" alt="Brisk Recurring Notifications create screen displayed with fictional documentation-demo data." loading="lazy" style="max-width:100%;height:auto;"><figcaption>The Recurring Notifications create screen in the Brisk documentation demo.</figcaption></figure>

Create a recurring notification after searching for the person, organization, item, location, or resource under alternate names and identifiers. Merge or correct an existing master record instead of creating a duplicate.

1. Select the business context first: **Owner**.

2. Enter the required identifying and operational values: **Label**, and **Body**.

3. Review **Alert Level**, **Frequency**, **Day Of Week**, and **Active** deliberately; these choices control availability or workflow rather than merely describing the record.

4. Save the recurring notification, then confirm **Label**, **Body**, **Notification Link**, **Alert Level**, **Owner**, and **Recipients**, plus the remaining screen fields on its detail page before continuing.

After saving: Verify this recurring notification in the next transaction or assignment screen before staff build new activity on it; correct ownership, classification, and active state now rather than after transactions accumulate.

<h2 id="bkmrk-delete">Delete a recurring notification</h2>

Delete this recurring notification only if it is an unused duplicate or setup mistake. Once other records refer to it, preserve that history and make the value inactive when the screen provides that option.

If the record is merely obsolete, use **Active** to remove it from future use while preserving existing references.

On the confirmation page, verify **Label**, **Body**, **Notification Link**, and **Alert Level**. After confirmation, return to the Recurring Notifications list and make sure only the intended recurring notification was removed.

<h2 id="bkmrk-detail">Review recurring notification details</h2>

Use the detail page as the shared record of what this recurring notification currently means. Verify **Alert Level**, **Frequency**, **Day Of Week**, and **Active** before relying on it for a decision.

Follow **Owner** to determine whether the issue is on this recurring notification or on one of those linked records.

Next check: Verify this recurring notification in the next transaction or assignment screen before staff build new activity on it; correct ownership, classification, and active state now rather than after transactions accumulate.

<h2 id="bkmrk-update">Edit an existing recurring notification</h2>

Edit this recurring notification to keep the same real-world party, item, location, or resource accurate. Do not repurpose it for a different entity after activity is attached.

1. Open the detail page. Compare **Owner** with the supporting document or approved request.

2. Recheck **Alert Level**, **Frequency**, **Day Of Week**, and **Active**. These values are most likely to change navigation, notifications, access, and other users’ behavior.

3. Save the change, return to the list, and confirm that the recurring notification now appears under the expected **Alert Level**, **Frequency**, **Day Of Week**, and **Active**.

After the change: Verify this recurring notification in the next transaction or assignment screen before staff build new activity on it; correct ownership, classification, and active state now rather than after transactions accumulate.

<h2 id="bkmrk-list">Find and review recurring notifications</h2>

<figure class="brisk-doc-media"><img src="https://help.brisksystems.us/uploads/images/gallery/2026-08/article-modelsetuprecurringnotification-list-recurring-notifications.png" alt="Brisk Recurring Notifications list screen displayed with fictional documentation-demo data." loading="lazy" style="max-width:100%;height:auto;"><figcaption>The Recurring Notifications list screen in the Brisk documentation demo.</figcaption></figure>

Use the Recurring Notifications list to find the correct record before opening or changing it. Compare **Label**, **Body**, **Notification Link**, and **Alert Level**. Records with similar names or numbers can still belong to different **Owner**.

Open the recurring notification whose **Label**, **Body**, **Notification Link**, and **Alert Level** match the task. If it is missing, clear the list filters and recheck **Alert Level**, **Frequency**, **Day Of Week**, and **Active** rather than creating a replacement immediately.

## Fields and business rules

Brisk stores 13 user-relevant fields for this recurring notification, including 1 linked-record selection and 3 controlled-choice fields. Create and edit screens may hide calculated or workflow-managed values from this full reference.

| Field | Required | What it controls |
|---|---:|---|
| **Label** | Yes | The title or description of this notification. |
| **Body** | Yes | The message delivered by this notification. |
| **Notification Link** | No | The destination that this notification will direct to. |
| **Alert Level** | No | Controls the notification delivery intensity. Available values: Bell only, Blocking popup, Popup and email. |
| **Owner** | No | User who manages this recurring notification. |
| **Frequency** | No | How often this notification repeats. Available values: Weekly, Monthly, Quarterly, Annually. |
| **Time Of Day** | No | Time of day to deliver the notification. |
| **Day Of Week** | No | Required for weekly schedules. Available values: Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday. |
| **Day Of Month** | No | Required for monthly, quarterly, and annual schedules. |
| **Month Of Year** | No | Starting month for quarterly schedules (runs every 3 months from this month) or the month for annual schedules. |
| **Next Run At** | No | Next scheduled delivery time. |
| **Last Sent At** | No | Last time this notification was delivered. |
| **Active** | No | Disable to pause this recurring notification. |

## What happens next

Verify this recurring notification in the next transaction or assignment screen before staff build new activity on it; correct ownership, classification, and active state now rather than after transactions accumulate.

## Common mistakes and troubleshooting

- **The record will not save:** Recheck **Label**, and **Body** and any message beside the field. A required related record may also be inactive or unavailable to your role.

- **The record saved but is not available where expected:** Recheck **Alert Level**, **Frequency**, **Day Of Week**, and **Active**, then clear the filters on the destination list. A saved record can still be inactive, unpublished, locked, unapproved, or in the wrong workflow state.

- **The values look right but the result is wrong:** Open **Owner** from the detail page. Correct the specific relationship that is wrong instead of forcing a total or status to compensate for it.