Best Practices for Slate Communications: 2023 Edition

This post contains terminology that will be familiar to seasoned users of Slate. If you’re new to the Slate universe, we recommend reading the first (and if you’re really curious, the second and third) installments of our previous three-part series on Configurable Joins. If you need a refresher on Slate-specific terminology, this glossary is also a useful resource.

July marked my four-year anniversary as an RHB employee, and this milestone prompted me to reflect on all the incredible experiences I’ve had as a member of the team. As part of my walk down memory lane, I took a moment to revisit my very first Insights article, written in August 2019, which discussed best practices for Slate campaigns. Although the fundamentals I outlined in that piece still hold true today, we’ve seen quite a few enhancements to Slate since the article was originally published. These new functionalities provide us with additional opportunities to consider as we develop our content, configure our messages, track our performance and create new pathways for reaching our audiences.

Given all this, it’s time to identify some new strategies for how we leverage Slate as a communication tool. Let’s start by taking a look at what’s changed since we last discussed communications best practices.

Configurable Joins Drive Everything

You probably knew that Configurable Joins would make an appearance in this post. The introduction of Configurable Joins (CJs) has significantly impacted how we access and utilize our data across the entire Slate database, including the Deliver module. With CJs, we can employ more robust exports for message merge fields, develop pinpoint precision when defining our audiences and leverage more relevant personalization for all recipients. With the advent of Query Libraries, we can quickly and accurately access all of this with just the click of a mouse. (Still trying to make sense of Configurable Joins? Check out RHB’s three-part webinar series.)

Audience Definitions Are Shifting

Ever since Technolutions first introduced drip campaigns, we’ve been configuring them via populations. Populations have been used to define which records are part of our audience and to specify the trigger for delivering each campaign message. In particular, the Population Timestamp Days filter has done a lot of heavy lifting when it comes to developing a campaign’s sequence and cadence.

But our audience parameters are changing, especially as we see institutions use Slate for more complex structures like graduate program recruitment. In these scenarios, building a population for each specific drip campaign could result in the creation of hundreds of additional populations and rules in the database. Given that populations already define so much in Slate—they manage everything from a user’s access permissions to the materials an applicant can upload to the custom tabs that display for a record—adding even more populations to drive communications campaigns isn’t always a sustainable solution.

Existing Tools Have New Functionalities

Many of the tools we’ve been using for a while have been upgraded in the past few years, introducing new opportunities for how we communicate with our audiences. Because of Configurable Joins, we can transform data in new ways to drive translation code values, exports and Liquid markup. Content Blocks, which were formerly known as Mailing Snippets, can now include merge fields and Liquid markup; in fact, users can even place Content Blocks within other Content Blocks, creating the dynamic content equivalent of Inception (however, if we’re hoping to keep your campaign maintenance simple, employing that level of Content Block complexity is probably not in our best interest). And Deliver itself now features Deliver Designer, which allows designers with the requisite HTML and CSS skills to configure design elements known as Components. End users can then insert these Components into Deliver mailings to create styled messages that align with the university’s brand guidelines.

Portals Offer (Almost) Limitless Possibilities 

Portals are one of the hottest buzzwords for Slate users, and here at RHB, we’ve helped institutions use them for just about everything. Portals allow us to drive audiences to customized landing pages or microsites that can be used for lead nurturing, progressive profiling and behavioral insights. Over the past several years, creating and maintaining portals has become far simpler for Slate power users thanks to the introduction of Configurable Joins, Dynamic Layouts and Components. Perhaps best of all, Express Portals now allow institutions to quickly build assets that don’t require queries or methods, making it easier than ever to add a landing page or two into your multichannel marketing plan.

But What Does It Mean?

It’s clear that over the last few years, we’ve experienced significant change across the Slate database. But how exactly do these updates impact the communications work we do in our instances? Let’s take a look at a few ways we can adjust our practices and processes in order to fully leverage our current Slate ecosystem.

Embrace the Power of Configurable Joins

If you haven’t already, making the transition to Configurable Joins for your campaigns and mailings is the single best thing you can do for your Slate communications. Doing so will offer you the opportunity to easily  utilize a wealth of data that had previously been extremely challenging to access. A few options worth exploring:

    • Loop Content Blocks: With a dictionary subquery export, Liquid looping and a Content Block, we can include unique dynamic content for data that links to a recipient with a one-to-many relationship. For instance, if our Program of Interest field is multi-value, we can create a dictionary subquery joining from Person to Field Values to Lookup Prompt in order to export each separate prompt value stored on the recipient’s Program of Interest field. Through Liquid looping, we can then use each of these prompt values to drive a Content Block export and merge them all into the mailing as unique blocks of content.
    • Redefine Translation Code Values: Sometimes, we may want to use a combination of a few field values to export the correct translation code value; for instance, a translation code may provide a counselor’s contact information based upon a combination of student type and citizenship. With Configurable Joins, we can accomplish this in a subquery. Add a subquery export, select Concatenate as the output and add the relevant data points to the export. At the bottom of the dialogue box, select the correct translation export from the Export Value drop-down list, specify which translation code should be referenced and let Slate do the rest.
    • Create Affiliate-Scoped Mailings: With Configurable Joins, we can develop much more robust communications plans for parents or other influencers. By using Relation as the base for a recipient list, each relationship record is a unique recipient, which means mom and dad will each get their own version of the email. We can include filters to define which relationship rows should be included, then join to the Person record to specify details about the students themselves. Within our exports, we can add both parent and student data points as merge fields, thereby creating a message that’s personalized to each recipient, both as a parent (consider inserting the student’s first name into the mailing instead of using generic “Your student” text) and as a person (using a parent’s first name is a lot more personal than “Dear Parent or Guardian”).
    • Build Evergreen Event Marketing Messages: Promoting upcoming events often results in a lot of emails, but instead of creating a separate email for each upcoming Open House event, we can utilize independent subquery filters and exports to create an ongoing message that’s always up to date. Within an independent subquery filter using the Form base, we can specify that we want the email to send if there is a confirmed event that has space available, uses our Open House template and occurs a specified number of days after today. Then, with independent subquery exports that use the same defined event parameters, we can add relevant event merge fields to the message so that recipients know the event date, time, location and registration link. By setting the message as ongoing and allowing recurring delivery, the email will be sent to our recipient list each time a relevant event is the specified number of days away.
    • Take a Shortcut with Query Library: Using CJs creates lots of new possibilities, but building all of those queries can be time consuming. Fortunately, Technolutions makes things easier for us with Query Libraries. With this tool, we can configure our most commonly used filters and exports, then add them to any query we’re constructing with one click. Query Libraries can be utilized in any part of Slate that uses the query tool, including portals, rules, reports and, of course, recipient lists.

Think Beyond Population Filters

I noted above that for many schools, it’s becoming increasingly burdensome to rely on populations to define recipient lists and message cadence for drip campaigns. This isn’t just true for institutions with numerous populations to manage. More and more, communications professionals desire the flexibility to be able to pause and edit their campaigns, then resume that comms flow without any recipients skipping a message. Other users may find that populations are unreliable because their audience definitions aren’t driven by data changes that would queue a record to run through the population rules. In circumstances where populations present potential limitations or challenges for an institution, transitioning to a sequenced query campaign can provide a better solution.

Sequenced query campaigns are driven by recipient list queries that assess a record’s data points at the specific point in time that the query runs. As a result, these queries can assess a wider range of data points, including some that may not trigger rules, such as message engagement or specific changes to an application’s decision status (this also means there’s no need to use retroactive refresh to ensure that records with more nuanced data are in the correct populations). Populations can be used as a filter component if desired, or query filters can be used instead.

In this recipient list, we’ve joined to the Rank 1 Released Decision [ 1 ], then specified that this decision has been either: a) received by the applicant at least one day ago [ 2 ]; or b) released to the applicant at least one week ago [ 3 ]. A simple admit population filter also exists so that the mailing includes only admitted students whose applications are in an active application period for the relevant academic program.

Within a sequenced query campaign, each message operates dependently. Each message in the communications flow (with the exception of the first message) references the delivery date of the previous message, then uses that data to determine when the current message should be sent. Because each message’s delivery is driven by the previous message’s send date, we can accommodate for pauses in a campaign, skip messages for specific records, send different versions of a message to recipients based upon their data points or even run leads through a campaign again once they’ve reached the end.

Message 3’s recipient list includes a filter to only pull records who were sent a version of Message 2 (either 2a or 2b) at least three days ago [ 1 ]. Because the recipient list for the first message in the campaign specified when admitted students should enter the campaign, based upon decision received/released date, this does not need to be replicated in the query for Message 3; instead, we only need to specify that the Admit decision is still the Rank 1 Released Decision [ 2 ].

Use Familiar Tools in New, Sustainable Ways

Although Technolutions has introduced a lot of new features over the past few years, updating your campaign process doesn’t always require learning a new Slate functionality. There are plenty of opportunities to examine the current tools we have and identify where we can be doing more with them by either taking a new approach or refining our business processes. Two of these that are worth considering are Content Blocks and form communications.

1. Content Blocks

I’ve loved Content Blocks for years because of how they simplify the processes for creating and managing dynamic content across campaigns. By linking the values for a variable data point (major, geographic location, student type, program of interest, etc.) to specific content created within a Content Block, we can create highly personalized communications that are consolidated for easier maintenance. 

But Content Blocks don’t always have to be for variable data points, and users can also leverage content blocks to centralize the maintenance of static content that’s used across many communications. For instance, our email footers might be standardized across lots of mailings within Slate—they’re in our templates, our form and event communications, our System folder messages and all of those emails that live in Deliver. These footers are everywhere, and because of that, it can be a massive undertaking to get them updated if we’re asked to adjust a web link, add/remove a social media icon, insert additional footer text, update a copyright year or modify branding. Instead of making these changes to potentially hundreds of emails, we can place the HTML/CSS for our footers within a Content Block. Then, when we build an email or template, we can add that Content Block, and by adding double quotes around the variable we’re referencing in the Content Block code, e.g. {{“footer” | snippet: “footer”}}, that static content is added to the message, referencing the same Content Block export each time. If (and when) we need to update the footer in the future, we just need to make adjustments to the Content Block itself, and all future messages sent will automatically update.

The footer Content Block includes a default, full-content option [ 1 ] as well as two simplified versions without social icons [ 2 ].

Because we’ve placed double quotes around the export value, Slate will search for no_social as static, rather than variable, content when determining which version of the footer key Content Block to insert.

Based upon the static no_social export value, Slate has inserted a version of the footer key Content Block that has a blue background and no social icons.

When we set up static content blocks, we should always include a default export, but we don’t have to be limited to just that. Consider creating a few different variations on this content; for instance, an export of “full_footer” could be added to emails that include all footer elements, while a “basic_footer” export could insert a simplified version for form and event communications. 

2. Form Communications

Speaking of form communications, these automatic messages also present us with new opportunities to make our comms flows more robust. Form and event communications have many similarities to standard Deliver messages, but these mailings don’t rely on recipient list queries and instead use triggers, sending based upon form submission data or information about the form or event. Because of this, Slate users may often view these messages as purely transactional communications, and this mindset will leave them missing out. 

Forms and events serve as the first source for many of our leads, who might fill out an RFI form on our website, provide their information via the registration form for a recruitment event, or sign up to attend a webinar or open house. When a new inquiry shows interest in our institution, it’s wise to immediately begin the lead nurturing process, but if we’re using a traditional drip campaign in Deliver, it may be a full day (or more!) before the recipient list query runs and the student receives their first campaign message—what a missed opportunity! Instead, we can use form communications to kick-start our drip campaign for these leads. Just like standard Deliver mailings, form and event communications can use variable content like Content Blocks and Liquid markup, so for RFI forms, we can copy the source code for the first message in our drip campaign and paste it into a form communication that uses the Upon Form Submission trigger (since merge fields are a bit different for forms vs. Deliver mailings, make sure they’re updated in the new form communication). 

If we choose to replicate the start of a drip campaign within a form communication, we need to ensure that our records won’t end up receiving both that form message and the Deliver mailing. Thankfully, Slate tools make this possible. In a form communication, we can use conditions, which operate much like exclusivity groups do for rules, to define which submitters should receive each version of a message. Configurable Joins are available when creating conditions, so we can join to the form submitter’s record to determine whether they’re a new inquiry who should receive the first message in our drip campaign or an existing lead who should instead be sent a simpler confirmation message. Within the Deliver version of this first message, a recipient list filter can exclude any records that have received the form communication version.

Finally, when it comes to form communications, let’s not forget about confirmation pages. Although these pages don’t need to be elaborate, they offer us a great opportunity to keep engaging with our new leads right after they submit a form. We can configure a confirmation page with a redirect script to send prospective students to a designated page on our website so they can continue exploring our institution; just allow for a 5-10 second delay so that your new inquiry sees the submission confirmation message. And if we want to make it even more personalized, we can redirect these inquiries to a custom, Person-scoped portal, where we can use Content Blocks or other dynamic content to display relevant information that’s directly tied to the data they shared.

Don’t Forget About Portals

Although the majority of this discussion has centered around email, Slate portals are an incredible tool for communicators to consider. With portals, we can easily display relevant institutional information, quickly adjust content when needed, and provide a highly personalized experience for our web visitors, all without using our institutional CMS. Slate portals therefore present an opportunity to continue nurturing our leads beyond our drip campaigns. When a student clicks a link in an email about visiting campus, query string parameters can pass their identity through to the portal and display upcoming events that are relevant based upon student type, program of interest, location or current lead status. If an individual submits an RFI form, a redirect script can take them to a personalized confirmation portal page that includes information about their assigned counselor or intended major. 

If customized portals feel like too much of a lift, consider Express Portals instead. Express Portals provide a simpler way for Slate users to create landing pages that can drive leads to take action, and we can tie them into our existing campaigns. For instance, we might send a text message to inquiries with the link to an Express Portal for our upcoming events, or we could direct our email recipients to an Express Portal that provides further information on the application process or financial aid. Because they don’t require queries or methods, Express Portals can be a great way to develop foundational portal skills while creating valuable marketing assets.

In the past year, Technolutions has introduced new permissions for portals that will allow Slate users to review and edit specified portals without having access to all portals within an institution’s Slate database. Given these improved security settings and updated functionalities, there’s never been a better time to expand our institutions’ portal portfolios.

Conclusion

We’ve covered a lot here, and reading through all these recommendations about Content Blocks and drip campaign filters and portals and everything Configurable Joins may have you contemplating how to configure yourself a clone to help you take it all on (or perhaps, you’re just wondering if you can configure yourself a long vacation). If you’re feeling a bit overwhelmed, I’ll leave you with two final bits of advice.

First, stay centered on your audience. Sophisticated communications flows and personalized portals and dynamic content will only be effective if they align with what your audience actually wants. Start by exploring what you know about your leads and what matters to them. Once you understand this, you can determine which tools and strategies outlined above will have the greatest impact on how you connect with your audience, and this can guide your path forward.

Second, don’t be afraid to ask for help. Slate is a big, complex system with plenty of tools and functionalities that can take users a long time to fully understand. The Slate community is an incredible resource for sorting through all the nuance that exists, and it’s also a great place to find inspiration. If you find yourself stumped and/or overwhelmed, a trip to the community forums might be just what you need to get over the hump. 

And if you’re looking for a team of experts to support your endeavors in Slate, we’re eager to join you. Whether it’s campaign development, portal design, database configuration or team training, we’d love to hear from you; reach out to us to start the conversation.

  • Spread the word
Megan Miller

Megan is a Senior Technology Consultant at RHB.