GET ACTIONABLE SLATE INSIGHTS

Stop editing branding in test first. We often see teams moving branding files back and forth between environments, not realizing the Branding Editor already lets you preview and publish in one place.

Here’s the method we recommend:

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

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”).

Slate’s default mobile template works fine, but it’s very generic. Many schools leave it as-is, even though a quick settings change will allow their existing Slate branding to appear on mobile.

Here’s a quick way to check:
📱 Open a live Slate form on your phone.
👀 Does it look like your institution?
⚙️ If not, go to: Database → Configuration Keys → Branding, Privacy, & Ping → Mobile Template. Select /shared/build.xslt and save. That’s it!
Give it about 15 minutes for the change to take effect, then test on mobile. This is one of the simplest, highest-impact branding fixes you can make in Slate.

As Slate AI gets better, the gap between an average response and a great one usually comes down to your prompt. If you’ve written a long, detailed prompt that actually works, don’t trust yourself to remember it next week.

Save it as a Snippet instead:

➕ Head to Database > Slate AI Snippets and create a new snippet with your proven prompt.
🗺️ Set a relative URL path so it only appears where you need it (e.g. “/manage/query” will limit the snippet to being used on the query screens).
⌛ Refine the snippet over time instead of starting from zero.

Those tiny edits compound. A slightly better snippet today means faster, stronger outputs every time you use it tomorrow.

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.

There will always be some people who don’t want to hear from you anymore. Regular checks ensure your communications stay compliant and respectful.

✉️ Mind Your Solicitation Codes: Ensure that donor preferences (do not contact, do not solicit) are respected in emails and transactional messaging.

? Respect Message Groups: Set up Message Groups to classify the types of communications you’re sending (e.g., Event Invitations, Campus Updates, Solicitation), and make sure every Deliver message is assigned to the appropriate Message Group.

? Check Seasonal Addresses: Collect start and end dates for donor addresses, and give donors the option to provide seasonal addresses so print communications arrive at the right mailbox throughout the year.

People don’t avoid new tools, they avoid bad ones. For example, no one clung to flip phones once something better came along.  If a tool is clunky or creates extra work, adoption of said tool tanks. But when it’s powerful, intuitive, and actually makes life easier, people are inclined to embrace it quickly. 

That’s the opportunity we have with Slate: its flexibility means we can replace painful processes with smoother ones. And when that happens, adoption isn’t a fight, it’s a relief.

Manually retyping an address is a huge time drain.

If you’re building an internal update form, you can pass address values through the query string so the form opens with the correct data entered. This is especially helpful when updating a custom address type that the “person” parameter won’t automatically fill in.

You can add parameters like:

1️⃣ &sys:address_block_country=US
2️⃣ &sys:address_block_street=123%20Main%20St
3️⃣ &sys:address_block_city=Burlington
4️⃣ &sys:address_block_region=VT
5️⃣ &sys:address_block_postal=05401

If you’re editing an existing address, include the address GUID so Slate knows exactly which record to update (&sys:address:id=[guid]).

They cost one cent per segment. And segments depend on character count and encoding. A standard SMS message allows 160 characters. Add an emoji or certain special characters and that drops to 70 characters per segment. Longer messages stack segments (and cost) quickly. Merge field length is counted based on the actual value, not the length of the merge field, so a long first name can quietly push a message into another segment.

Before a large send, check the segment estimate under the message field. If you’re near a threshold, tighten the copy or remove emojis. Small edits can cut your cost significantly.

If Slate feels sluggish, your rules queue could be the culprit. Long-running or error-prone rules don’t affect just one process, they pile up, delay other activity, and quietly slow the whole system.

Slate can show you exactly where the drag is:

1️⃣ Go to Database > Rules > Check Rules
2️⃣ Sort by Duration and look for anything in red (30+ seconds) or showing ERR counts
3️⃣ Pick one rule and tighten it up. Use exclusivity groups, refine filters, or rethink trigger logic to reduce overlap

You probably don’t need a full rules overhaul. Making small improvements each time you visit this screen keeps your database healthier over time.