GET ACTIONABLE SLATE INSIGHTS

We see teams manually juggling new branding files between environments when the Branding Editor already handles previewing and publishing for you:

📥 Import current branding files.
✏️ Make edits.
🔎 Preview as a real record inside the Branding Editor.
🌎 When you’re ready, publish your new Branding for the world to see.

You still get to test thoughtfully in a controlled environment. You just remove extra file management steps by doing it all in Production, inside the Branding Editor. Fewer handoffs = Fewer chances to misplace something.

What it does: This one’s a bit of a niche developer feature, but it’s pretty neat. Drop in any GUID (person, interaction, form, user, source format… anything) and instantly see all the tables where it appears.
 
Why it’s useful: This is helpful when you’re trying to figure out what something really is (for example, “Oh, it’s not the person page form, it’s the tab it’s displayed on”) or when you want to see everything someone has touched (like, “Ah, this user GUID shows up on a lot of field updates”).

Many Slate teams still lean on birthdate or age-based logic to approximate student intent or class year, especially in inquiry communication flows. The assumption is that age equals readiness. In practice, this creates messy overlaps: students routed into parallel messaging streams that conflict with their stated entry term, or worse, pushed to apply when they’ve explicitly said they’re not ready.

As teams mature in Slate, most move away from birthdate-driven logic in favor of clearer, student-owned data points like entry term or graduation year. Systems (and people) behave better when key groups are defined by intentional, stable fields rather than inferred ones.

While you can create subfolders under Templates, Deliver will only display templates saved at the top level when you’re building a new message. The subfolder templates still exist, but they’re effectively invisible in the editor. This is very important to know BEFORE you start reorganizing your Deliver mailings.
 
Heads up: There’s an active feedback request to support this functionality that you can vote and comment on here: https://feedback.technolutions.net/ideas/PROD-I-3575

When someone says no, believe them. If a student has denied, withdrawn, or declined your offer, it’s a safe assumption they don’t want the next “Don’t forget to visit” reminder. Slate can handle this for you. But only if you’ve wired it correctly.

Ask yourself these questions to streamline your communications:

➕ Are you setting the opt out tag via decision? Decision codes can be configured to automatically set the Opt Out tag when the decision is released. Look for this setting on Deny, Withdraw, Admit/Decline, Waitlist/No, etc.

🔍 Are opt-outs applied correctly in your applicant pool? Check for opted-out students without a decision, or decided records that should probably be opted out. If you spot gaps, examine your process and build a regular check to prompt action.

✉️ Are you actually using the opt out tag (or message groups) in your communications? It’s common to skip it in application messaging since it’s mostly transactional, but verify that anywhere you could remove opted-out students, you actually do.

If you spot inconsistencies, adjust the process and set a recurring check. Clean exits are part of a clean build.

Updating portals gets slower and harder when nothing is named clearly. Documentation is hard enough to put together, so save yourself some steps with a few small shifts in how you use and name your views.

➕ Name your views, methods, and queries so that it’s immediately obvious which ones go together and how they work together to build the portal (e.g., *Default View ↔ *Default Method, TAB 1: Home, POPUP: Details).

🧭 Add a README view. Create an unlinked view labeled “INTERNAL: README” with notes about portal structure, dependencies, and anything fragile.

📦 When editing, make backup duplicate copies of your static content and move them into a designated “Backup” view before making major changes.