Creating a Daily Campus Events Communication

A daily campus events communication can be built with forms, content blocks, Liquid markup, and a recurring Deliver mailing. The pattern lets campus partners submit events or announcements through forms, lets staff approve the content, and then displays approved items in a recurring message.

   

       

⭐ Get Inspired

   

   

This article was adapted from a post by Technolutions staff in the Slate Community Forums' Get Inspired space. Have a great idea for a Get Inspired post? Let us know!

Plan the content sources

Start by identifying the types of content that should appear in the communication. Examples include:

• Upcoming campus events.

• Varsity or club sport games.

• Dining highlights.

• Performances or student activities.

• Campus-wide announcements from offices such as the registrar, campus safety, or parking.

Create intake forms

1. Create one or more forms to collect the content that should appear in the communication.

2. Add fields for the display values needed in the mailing, such as title, date, location, description, and link.

3. Add an internal-only approval field, such as Approved.

4. Create an Upon Registration communication to notify the Slate user or team responsible for approval.

Only approved responses should be eligible to display in the daily mailing.

Create content blocks

Create a content block for each content source or section. The content block should reference the exports that will be returned by the mailing's recipient list query.

For more information, see Dynamic Content Blocks.

Build the recipient list query

1. Create the Deliver mailing and open the recipient list query.

2. Add an independent dictionary subquery export on the Form Response base for each form that supplies content.

3. Filter the subquery to return approved responses and the relevant date range.

4. Add exports for each form field that the content block needs to display.

5. Use computer-friendly export names, such as eventname, eventdate, or location.

📝 Note

The export names in the dictionary subquery must match the merge fields used in the content block. Use concise, computer-friendly names to make Liquid markup easier to maintain.

Display the content block in the mailing

Add the system current date as an export in the recipient list query. Then use that export to call the daily content block in the mailing:

{{System-Current-Date | snippet: "dailycontentblock"}}

The snippet and block filters can both be used to output content blocks. See Content Blocks for more details.

Add fallback content when nothing is available

If the communication might not have approved content every day, add an existence export that returns 1 when approved content exists and 0 when it does not. Then use Liquid markup to display either the content block or fallback text:

{% if upcomingexists == '1' %}
{{System-Current-Date | snippet: "dailycontentblock"}}
{% else %}
There are no upcoming events.
{% endif %}

Configure the mailing schedule

1. Create a message group for this recurring communication.

2. Configure the mailing to send on a recurring basis.

3. Set the desired interval, such as once every day.

4. Set deduping to Allow recurring delivery of this message to the same recipient.

5. Configure delivery windows and review the mailing before activation.

Using a dedicated message group lets recipients unsubscribe from this specific communication without unsubscribing from all institutional messages.

Additional considerations

• Use Liquid markup to suppress the mailing for a recipient when no content exists.

• Use Deliver Designer if the communication should share a reusable marketing template.

• Adapt the same approved-content pattern for a portal instead of a mailing.