Site Going On Hiatus

What is a Hiatus:

Customer wants to take a planned, extended break from their event.

Why would someone go on Hiatus:

Could be a seasonal shift (most common for summer, especially), they are doing some remodeling/renovations and will not be open, or they are evaluating their event programming for the time being.

How does the process work: 

FIRST: Hiatus Begin Form is filled in (Sam or admin) noting the start of the hiatus, a note (reason for the hiatus provided by customer), and a potential return date (if provided by customer).

THEN:

Hiatus Start Notification

1. When the start of hiatus is within 15 days the Hiatus Start Notification automation sends an alert to #existingevents-alerts tagging Brenna and Chuck to alert them of the upcoming change.
2. MaryKate is cc'd on an email sent to the host alerting them of the upcoming hiatus.

Hiatus Start Status Change

When the final show before the hiatus begins has been performed the system takes the following steps

1. Updates the Status of the Schedule to Hiatus, removes the attached host, and changes the Host Changing status to "on hiatus"
2. Sends a Slack message to Sam alerting them that the event has gone on hiatus and nudging them to send the hiatus survey. 
3. Sends a Slack message to #existingevents-alerts tagging Chuck to stop billing, Sam and MK to update the calendars, Marketing to update socials, what's happening, and the website, and AV to pickup any AV equipment.

Reality Table Entries

The system needs to identify and clear any existing Reality Table entries for after the start of the Schedule's hiatus.

End Events on Schedule Table: When an event is put on hiatus, the information is sent to the Font of Reality where the Schedule record is updated with an "end after" date. This stops the creation of new future Reality Table entries.

Delete all Reality Table Dates after Final Show: Airtable looks for all Reality Table entries with a date that is greater than the end date identified. It marks them with a "Marked for Deletion" checkbox. This checkbox puts them into a Marked for Deletion view, cueing a Zap to delete the record. This automation split is due to the inability for Airtable automations to delete records, or for Zapier to do an action on a repeated list of records.

What If:

What if they want to run a theme night during the hiatus?

They would like to return from Hiatus?

FIRST: 

A SAM fills in the Service Return Date in their Hiatus Management Interface. This date is the first day of service after their hiatus is over.

THEN: 

Hiatus Ending Notification

When the Service Restart Date is within 21 days of today the following actions will occur.

1. Update the Host Changing status on the Schedule to confirm host returning (from hiatus or long term sub)
2. Update the Schedule Status to Return Pending
3. Sends a message to #existingevents-alerts telling Chuck to start billing, Staffing to confirm the host for the location, and Marketing to create a new ad announcing their return
4. Sends a message to #website tagging Marketing to update their page to remove the Hiatus indication.

Return to Active, End of Hiatus

6 days before the Service Restart Date the following actions will occur

1. The Schedule Status is updated to Active from Return Pending
2. The Site Status is updated to Active
3. Message is sent to #existingevents-alerts to as a reminder and to prompt Marketing to update the website landing page. 
4. Life Cycle Status is updated to Completed

Reality Table Entries

The system needs to rebuild a Reality Table entry to restart after hiatus.

Rebuild Hiatus Restarts to Schedule Table

When a Service Restart Date is entered the Reality Table rebuilds a new Schedule Record. This starts the same chain of automations as a New Site Start to build the new Font of Reality dates and Reality Table Entries.