---
schema_version: "1"
id: 0dbd1f32f474e57bca36b0df19a785d374d3052be4f8861199dc46f7db61e16b
title: Send Reminders After Waiting for an Event Example
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/platform/264-0-0/flow_ref_elements_wait_examples_looping.md
canonical_url: https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_wait_examples_looping.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: 62f31d9dbdc0e0073bd5b1ff1b206ffe0f15c1fb148a1cb8645fdc2b52a64ea7
description: Create a flow that sends multiple reminders after waiting for several time-based events, such as two weeks and one week before a contract ends.
products:
  - Flow Builder
  - Salesforce Platform
release: "264"
---
# Send Reminders After Waiting for an Event Example

Create a flow that sends multiple reminders after waiting for several time-based events, such as two weeks and one week before a contract ends.

### Required Editions

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small edition"><colgroup><col></colgroup><tbody><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;"><a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_supported_editions.htm&amp;release=264.0.0&amp;type=5" title="Learn about the editions and user interfaces that support Flow Builder. Some Flow Builder features integrate with other Salesforce products that require additional licenses.">View supported editions.</a></td></tr></tbody></table>

You're designing a flow that reminds contract owners to follow up with their customers before the contract ends. Rather than sending just one reminder, however, the flow sends them regularly. This example shows how to use one Wait element to send a reminder two weeks before and then again one week before the contract ends. You could easily extend this flow to send reminders at more intervals, such as three days and one day before the contract ends.

## Example

This flow already contains these populated variables. Before the flow runs the Wait element, it looks up and stores the contract's **EndDate** and **OwnerId**.

- **{!contract}** is a record variable that contains the contract's **EndDate** and **OwnerId**
- **{!contractId}** is a text variable that contains the contract's **Id**
- **{!oneWeekVisited}** is a Boolean variable whose default value is {!$GlobalConstant.False}
- **{!twoWeeksVisited}**is a Boolean variable whose default value is {!$GlobalConstant.False}

![Screenshot of a sample flow that is waiting for an absolute alarm event](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-platform_automation-264-0-0-production-enus/60568438-ec7e-4665-acd1-7c80dcbe60d5/platform_automation/images/flow/flow_wait_looping.png)

Because the flow sends the reminder emails both two weeks and a week before the contract's end date, the Wait element defines two time-based resume events that use record-based time.

![Tip](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-platform_automation-264-0-0-production-enus/60568438-ec7e-4665-acd1-7c80dcbe60d5/images/icon_tip.png)

Tip Every time-based resume event consists of a base time and an offset. For record-based time, the flow needs three pieces of information to determine the base time: the object, the date/time field, and the specific record. The offset for record-based time works the same as it does for flow-based time. The flow must know the unit (either Days or Hours) and the number of those units. To wait for a number of days or hours before the record field, set **Offset Number** to a negative integer.

For both of these events, the offset is declared in Days, because weeks isn't an acceptable offset unit.

The base time for the first event ("2 Weeks") is the value of **Contract.EndDate** (1) on the record whose ID is stored in **{!contractId}** (2). The offset is -14 days (3) to represent two weeks.

![Screenshot of the first event's parameters](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-platform_automation-264-0-0-production-enus/60568438-ec7e-4665-acd1-7c80dcbe60d5/platform_automation/images/flow/flow_wait_looping_overlay1.png)

You want to use the same Wait element for every reminder, so after a flow interview sends one email reminder, it returns to the Wait element. But first, to ensure that the interview doesn't send the same email again and again, use wait conditions. When an interview runs a Wait element, it first checks the conditions for each wait configuration to determine whether to wait for those events. If a wait configuration has conditions set and those conditions aren't met, the interview doesn't wait for the associated resume event.

For the first resume event, the interview checks whether the Boolean variable **{!twoWeekVisited}** is set to false. The variable's default value is set to {!$GlobalConstant.False}, so the flow waits for the event until the variable's value is changed.

![Screenshot of the first event's waiting conditions](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-platform_automation-264-0-0-production-enus/60568438-ec7e-4665-acd1-7c80dcbe60d5/platform_automation/images/flow/flow_wait_looping_conditions2.png)

Indicate what the flow does when the "2 Weeks" event occurs by connecting the Wait element to other elements. Then, before you return the flow path to the Wait element, change the value of **{!twoWeeksVisited}** to {!$GlobalConstant.True}. You can do so with an Assignment element. If the value for **{!twoWeeksVisited}** isn't false when the Wait element runs, the flow doesn't wait for the "2 Weeks" event to occur. Essentially, the interview checks whether the first resume event has occurred yet, since the variable is changed to true only in the associated wait configuration's path. If that resume event has occurred (and the variable isn't set to false), the interview knows not to wait for that event.

The second event ("1 Week") has the same base time as the first event; the offset is -7 days to represent a week.

![Screenshot of the second event's parameters](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-platform_automation-264-0-0-production-enus/60568438-ec7e-4665-acd1-7c80dcbe60d5/platform_automation/images/flow/flow_wait_looping_overlay2.png)

For the second event, the flow checks whether the Boolean variable **{!oneWeekVisited}** is set to false. If it isn't, the flow doesn't wait for this event.

![Screenshot of the second event's waiting conditions](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-platform_automation-264-0-0-production-enus/60568438-ec7e-4665-acd1-7c80dcbe60d5/platform_automation/images/flow/flow_wait_looping_conditions1.png)

Like with the first wait configuration, use an Assignment element to change the value of **{!oneWeekVisited}** to {!$GlobalConstant.True} before the flow path returns to the Wait element. As long as **{!oneWeekVisited}** isn't false, the flow doesn't wait for the "1 Weeks" event to occur.

![Tip](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-platform_automation-264-0-0-production-enus/60568438-ec7e-4665-acd1-7c80dcbe60d5/images/icon_tip.png)

Tip When a flow runs a Wait element and all the wait configurations have conditions that aren't met, the flow runs the default path. Because this flow is finished after it sends the final reminder, don't connect the default path to another element.

Just in case something goes wrong, set a fault path. In this example, the fault path sends an email that contains the fault message to the user who created the flow.