Stump the Slate Squad: Your Questions, Answered

Last month, Carnegie’s Slate experts teamed up with Technolutions to host a Stump the Slate Squad webinar. With hundreds of institutions tuning in, the questions poured in—everything from quirky form logic to complex reporting challenges and student record edge cases. This blog captures all of the questions we answered during the webinar (and all of the questions we didn’t get to live), along with detailed answers straight from our strategists and implementation pros. Whether you’re a Slate newbie or seasoned superuser, you’re bound to walk away with new ideas, best practices, and maybe even a Slate workaround or two you haven’t seen before.

Want to explore your question further or have additional inquiries? Join us at our Sip ‘n’ Slate and Social during Slate Summit 2025 or start a conversation to discuss how we can assist with your Slate needs.

Consolidate Records

1. Our consolidate records have not been updated in quite some time, and we know there should be records to merge. What is the solution?

2. What triggers records to be re-considered for Consolidate Records? Specifically, are low priority emails and addresses considered? Any tips, tricks, and insights would be great.

This most often happens when a new record is created through a person filling out a form, registering for an event, starting an application, or even when files are uploaded via Upload Dataset, but can also be included in Consolidate Records when a data point is updated or changed (like email address, for example). If Slate can’t make the automatch match (First + Last + Email OR First + Last + Date of Birth are all the same), but will show up in Consolidate Records if there are data points that match (like the same email but a different first or last name). For items like addresses and email addresses and their priority (Low, Normal, High), as long as they are at one of these priorities and not set to “Inactive,” they will be considered as possible data points for matching.

We would recommend always clicking the “Refresh All” button each time you go into Consolidate Records, and if there are enough data points that are the same between the two records, then they will show up as possible matches. NOTE: Any record that hasn’t been updated for 90 days falls out of view of the Consolidate Records tool. One way to ensure that person records have an update would be to create a person-scoped field (like a bit field or text field) and then build a query for all the person records where you want to add this value, add the value in the field through batch management of the query results, and then the records will have had a recent update made and be eligible for Consolidate Records again.

One of the other main things to keep in mind is also the quality or completeness of the data that is coming into your Slate instance. Are you collecting First Name, Last Name, Email, and Date of Birth on all forms? Do you have name buy lists that are missing the Date of Birth field, and do prospects or inquiries provide a shortened name, preferred name, or nickname instead of their first name? (e.g., Andy instead of Andrew).

A couple other tips and tricks would be to spend a little time each day, if possible, in Consolidate Records merging or excluding possible matches, as that will keep things from building up. Do a “Refresh All” in Consolidate Records after loading large files into Slate.

Lastly, you could build out other audit queries that look for other possible matching data points, and you could also build out a Consolidate Records Dashboard if you want to be able to compare additional fields as you are merging/consolidating records.

We have noticed that it’s been difficult to filter out transfer students, even after filtering “not in: transfer student and first year transfer student.” Any way to completely exclude a particular student type?

It could be a result of the fact that the duplicate records have mismatched student types. For example, if you’re filtering out transfer students, but you have a person who has a record with a freshman student type and a potentially duplicate record with a transfer student type, it will not filter that person out of the view. If you want to be sure you’re not merging a record with a certain student type, it’s probably safest to create a Consolidate Record Custom Dashboard and include said student type in the dashboard. This way, those who are merging records can skip or exclude those records.

Workflows

We have a group of high school counselors on campus each year to review applications for a scholarship. We are considering setting up a workflow for this scholarship application and giving those high school counselors external user accounts to allow for an online reading experience rather than us printing packets with application materials in them. Is this something you would recommend, what are some potential issues with doing this?

This is a workable idea, but there should be a few security considerations if you choose to go this route.

• Make sure to set an inactivation date so account access is automatically removed when the time period is over.
• Add the workflow to a realm.
• Add a custom permission to the workflow and add ONLY that permission to the record. Alternatively, a custom Portal may be a better solution from a security standpoint. You can leverage the Organization Dataset and provide login credentials for those records, and create a completely custom/accessible/mobile-responsive environment.

Permissions

Is there a way to provide queries to faculty without granting query user permissions within their user account, or without building a portal to use the queries?

This is a tough question, but one that a lot of institutions ask. The short answer right now is, sadly, no, there isn’t a surefire panacea to address this situation. Your current best bet probably IS a portal. But if you are comfortable granting some basic query permission access, you open up some additional options. For example, just giving the user permission called “Query” means a user can only access those that they’ve been given direct permission; the tradeoff is that they can create their own. But at that point, the Grantee feature within each query is usable.

To access, find the button called Edit Permissions within your query builder. Click Add Grantee, and you can then select based on User, Role, Permission, and more what someone can do (such as just display/run the query or edit it).

You can also consider Realms or maybe Population Permissions, depending on the specific use case, and I know the Knowledge Base walks through several scenarios. And in the case of queries, they can be organized into Realms to facilitate the separation of permissions regarding who can create, execute, and modify them, without influencing queries in other Realms. While a user’s capabilities are still governed by User Permissions, Realms ensure that their effects are confined to relevant objects only. But you have to be extremely careful using Realms, and strong/consistent data governance and internal policies and procedures are key to these functioning as intended. Proceed with caution! We definitely work with an increasingly longer list of schools that make heavy use of population permissions, too.

Origin Sources

I’ve made updates to origin sources, but am still seeing many records without appropriate origin sources as I’ve set them. I thought they all refreshed overnight?

Origin Sources are quite flexible and can be updated at any time, with changes typically recalculating overnight. But there is one exception: if a record hasn’t been updated within the past year, the origin sources for that record won’t automatically recalculate. To get around this, you can create a custom person-scoped field called “Origin Source Update,” set it as free text with a date data type, and use it to trigger an update. To do that, you’ll run a query on the records you want to update and apply the field using the current date. Applying the field will now prompt the instance to recalculate the origin source for those records, and it gives you a useful reference point for any future forced updates.

Rules

Write a rule that updates an app-scoped field on the second application received within the same period based on their attendance at a specific event. Real life use-case: We have a fly-in program that students apply for using a Slate-hosted application, and if accepted they then attend an app-scoped Slate event. If that student then applies via the Common App, and therefore has a second application in the same period, I need to update a custom app-scoped Yes/No field on the Common App round tab indicating that they attended the fly-in event. We worked on this at last year’s Summit Sip-n-Slate, and thought that an independent subquery filter was the answer, but that solution didn’t end up working. The rule always updates the field on the 1st app (the fly-in application).

Luckily, we chatted with Courtney, who remembers this issue and dug in a bit further! We do believe the rule should still work, but that you may actually not need an independent subquery. In thinking about how to troubleshoot this, make sure to look at a few specific aspects of the rule:

• Include a filter added to ensure that the application that you’re looking to update is the new one, not the original application. We wouldn’t necessarily recommend using Application Rank because that could shift based on a variety of factors. Instead, consider status timestamps and comparison filters.
• Since you are looking to update one application based on another application, make sure that you’re joining from Application > Person > ApplicationS. Without that circular join, you’re going to be referencing the same application that needs to be updated, rather than the one that has the data point to trigger the rule.
• When trying to troubleshoot, head to a quick query and create the same filters but as exports instead—e.g., if you have a filter comparing timestamps of applications, add those timestamps as an export in the query to ensure that the data is actually capturing the right information. If that’s not right, then your filters will never be right.

Come back to our Sip’n’Slate this year if you are still unable to get it. We’d love to dig in again and get this right for you!

Forms

We have a form for applicants to provide a second choice major if they are not accepted to one of our more competitive majors. This form is app scoped and we send an email message with a link to the form to be completed. In a query we have a datediff formula export with the delivered date of the email and the form submitted date. The applicants have 10 days to complete this. Is there a way to get this data to be on the form (hidden from the applicant) for internal use for our operations team?

Yes! You’re already on the right track with using the datediff formula in the query; we’ll also need to do that as an export on the form. This may get a little complex as we’ll be going three layers deep on our datediff value, but I’ll walk through it step by step.

First, you’ll go to the Edit Properties button on your form. Then to your Merge Fields tab. We’ll want to create an export here that looks for that difference between the two dates. So you’ll create a subquery export (and we’ll be going down a few levels of subquery exports to make this work). Within this top layer, you’ll create another subquery export. In this second layer, we’ll create the datediff formula to compare the number of days between these two dates. You’ll need exports to compare, so we’ll create two subquery exports: one for the date that the message was sent (in my example, I’m using the person created date as the date since I don’t have an email send date). Then in the second date export, you’ll join from your form to Application and then from Application to Form Responses (in this example, “Second Chance Major”). You’ll select this same form as the one you want (thus use “Specific form, event, or template”) and navigate to the folder and the name of the form. Once you’ve made those joins, you’ll just want the Form Submission Date as your export. Then you’ll have your formula of datediff(day, firstdate, seconddate). Finally, click all the Save buttons to get back out to our Merge Fields tab again.

The last part will be to add an instruction block on your form and check the option box that says “Internal only” so that it won’t be visible to the applicant, but will be visible to your operations team. Then you’ll add some text, such as “Days between email sent and form submitted,” along with the merge field we just created. Then, once the form is submitted by the applicant, this form submission date will be populated, and Slate will calculate the difference between these days and display it as essentially “read-only” data on the form response.

I need to omit certain majors for international students. I have tried setting filters on the majors field on our application. Each time, it is either timing out or the major to be omitted for international students is still populating. What can I do?

I don’t know exactly how the pages of your application are set up. I would guess, though, that it’s like most Slate instances with citizenship on the Personal Background page and the field for selecting the major on another page. If that’s the case, you would want to make sure that the applicant answers the citizenship questions first before they can select the major they want to apply to since this data will need to be saved to those system fields so that Citizenship Status is able to be calculated. There are things you can do to ensure that a person’s Citizenship Status is set before the applicant can choose a Major.

If you don’t already, you’ll want to have hard fail rules for the citizenship questions and application major. On the Application Major field you can have an existence filter for Citizenship Status so that it will only display when there’s a value saved to that system field. You could also have help text/instructions to display there if Citizenship Status doesn’t exist that points the applicant back to the Personal Background page to answer these questions first. Then, when they return back, they will see the Application Major field and the help text will be hidden.

Then you can add some prompt logic only on your Majors that are just for US Citizens (or even Permanent Residents if they are able to apply as well). So your prompt logic could just be Citizenship Status = US Citizen for those specific majors that international applicants cannot apply to and then the rest of the prompts would have no prompt logic, that way they will show up for all applicants regardless of their citizenship status. Another good rule of thumb when adding filters to fields or in prompt logic is to do that in the affirmative, meaning, who should see this field or this prompt rather than who shouldn’t see it.

How do I set up a widget table and a digital signature? I need to create an online application for HRD classes that are fee waiver. AB Tech has it on their website and it would be the same info for us. Applicants will need to say if they qualify for 1, 2, 3, or 4 and sign digitally for us to be able to substitute that application for the paper one we currently use.

Widgets are only available in a few locations: custom tabs and application pages. Since this is on an application, you will need two forms: the application page and the widget form. The widget form will contain the fields displayed on the pop-up of each widget row. The table display of the entered rows is dictated in the Custom List Fields of the widget form.

For electronic signatures, as long as you include clear language on the form (talk to your legal team, but typically something like “typing your name and submitting this form constitutes a legal signature”), you should be all set. There are a number of community forum posts asking for a more direct electronic signature integration, so head over to the forums and upvote those to show your support. However, if this feels more like a radio button or select list type of question, you can include the description of each in an instruction block and then have the user select what corresponds to their circumstances.

Queries

I am working on creating an Organization Statistics Dataset Row Query using the suitcase in the Knowledge Base. The prospect/inquiry terms come from an entity. How do I use the Lookup Prompt base to return the counts for the prospect and inquiry columns?

Let’s start by breaking down how this query functions. It is a “lookup prompt” based query. This means that each row will be a distinct prompt value. To count the records associated with the term prompts that we’re using as our exports, in our aggregate subqueries we are joining to the person table from field values from lookup prompt. This gives us a direct 1:many relationship as one prompt value can be related to many field values. You cannot join from Field Values to the specific entity, so you will need to build an independent subquery export on the person base with a subquery filter to compare the entity term to the prompt value, along with filters to find the right person records and the organization record. In general, use subqueries as a starting point for 1:many relationships.

I created a user dashboard (cfd615af-8378-4103-b3d8-789d396508c3:hou) after getting inspired by this Community post. It’s supposed to show our counselors how many unassigned emails they have in their gateway inbox. Unfortunately, I keep getting a timeout error. Any advice?

Regarding the timeout error you’re experiencing with the user dashboard, here are some insights and potential solutions:

• Message Table Size: It seems the message table is too large for the dashboard query to render. The high volume of inbox/external emails is likely causing the query to time out. This can be addressed by limiting the dataset or reducing the number of emails being processed at once.
• Query Adjustment: When recreating the query in the query module, adding additional filters such as type: external mailing and a specific user does help the query run more efficiently. However, it appears that the issue lies with the export of the count. When using the aggregate and count functions, the query struggles to render the data. You could try the following:
  • Recreate the query with additional exports (such as user base with message/message mailing joins). This query should not live on the dashboard, but rather be run in the query module of Slate. You can view the information there directly.
  • Create an export/import loop query that populates a field displaying the count. This would be a once-a-day update (not live), but it can be added to the user dashboard so that counselors can view their count first thing in the morning.
• Home Page Report: Since reports generally take longer to time out, another option is to create a home page report that includes the user and count information. Reports are less prone to timeouts than dashboard queries, so this approach should be more reliable for displaying the necessary data.

Upload Dataset

How can you preserve an applicant’s email that was used to create their application account? We’re finding that subsequent uploads can change the email they used to log in. We have tried mapping uploads for emails to be low priority, but if email is the same, both become low priority and the student cannot log in, or if the same email is both normal and low priority, they also cannot log in.

I’d be curious what kind of volume you’re seeing that students are overriding emails used to create their application, along with what sources might be doing that. That doesn’t sound like typical behavior. Changing the priority can have some of these consequences, but it’s not often we would see brand new emails for current applications replace the existing email. Have you tried setting the application’s email address as a high-priority one, before anything else comes in? The rank 1 email address will always be used for portal login, and our collective favorite Knowledge Base article, Database Structure and Determination of Table Ranks, gives a full rundown of how rankings are determined. In addition, Slate runs a nightly cleanup of duplicate data specific to device types, and that lives in Database in a module called Cleanup / Scrub Address Records. Run that manually and see if that fixes things, and perhaps this is a timing issue as well.

Is there a way to automate uploads coming from College Board or Encoura? Any tips on how to manage and organize these kinds of uploads so it’s not so much of a lift?

While Encoura does support automation of their data files into Slate via SFTP, it’s not exactly plug-and-play. You’ll need to coordinate with Encoura to enable SFTP delivery, then configure your Source Format in Slate to automatically process the incoming files.

On the College Board side, there’s exciting news: for the 2025/2026 cycle, they’re rolling out a Search Output File SFTP option for Student Search Service orders. This will allow institutions to securely receive search files directly in their Slate SFTP environment. Our enrollment data team is looking forward to testing this new option with our partners and building more streamlined automation from it.

Whether you set up the automation or continue to upload the files manually, be sure to use the latest source format from the source format library. This will ensure that the data file you receive matches the standard layout, saving your time when mapping the fields.

Devices

What is best practice in devices for when the applicant is assigned our institution’s .edu email address? If you create it as a new device type, the record will not get picked up as a duplicate if they later use their .edu email address on a form. It will also not get matched in inbox if it is used to contact admissions. It is important to have it as its own type for comms that are only sent to .edu address. We have been putting it in 2 places, as low priority under the email device type and as its own device type.

There’s not a one-size-fits-all approach for this, as we often see schools utilize a new device type for a campus email, but there are some unintended consequences of that, so it really does depend on your business process. The key part of assigning a campus email address to a record is that it won’t affect their admitted student portal login. Often schools will utilize a campus email to students for them to access their portal once they are admitted/deposited, but the device type has to be the standard email in order for it to override. That new email also has to be a higher priority than their existing email. Slate will then adjust the student’s login username to the new campus email, without adjusting the password or PIN. The student would need to be notified they have to use their campus email to login. If communications are important to keep separated for campus emails I would recommend adding a subquery filter to the population or query in order to only grab campus .edu email addresses.

Regarding duplicate email and mailing addresses, where one is normal priority and the other is low priority…. is there an easy way to identify those records and remove/merge the duplicate email or mailing address, leaving one email or mailing address with a normal priority? Similar to how we merge schools in Consolidate Records.

There are a few ways (of varying complexity) that we could address this. Let’s break the process into two sections: identifying and acting.

• 1a. Identifying duplicate mailing addresses. For our address example, start a quick query on the person base, and then build a subquery with a comparison aggregate. Then create two sub-subqueries for the value of the Rank 1 address and Rank 2 address. Note that you’d have to join to an address table as part of this journey. You can then compare these sub-subqueries. Once you save this part, you are good for filtering.
• 1b. Identifying duplicate email addresses. A slightly more complex process is needed for email address priority, but the steps are pretty much identical. You’ll just want to think about the Devices table and filters for type and priority. For any of these examples, I recommend exporting a unique identifier as well as the two suspected duplicate data points to check your work in progress.
• 2. Acting (clearing out the duplicate data). In either case, you are better off deleting the one you don’t want (there’s not really “merging” here in the tradition sense). You probably should do that one at a time using the list you generated if you are new to any of these concepts. But, once you get comfortable, you could build a retention policy to help you.

Worth mentioning one of our favorite KB articles to understand where duplicates come from: Matching Criteria for System Objects (Schools, Tests, Interactions, and more).

Deliver

Can you reset someone to start an email campaign over? For example, you have a record with a bad email that never got campaign emails and then later we get a good email from another source. Is there an easy way to reset/have them start the campaign over? We have prospective students missing important emails.

Unfortunately, there is no easy way to have Slate know to do this automatically, so this is a manual process. If you find yourself having to do this often, you could create a custom tag to use specifically for situations like this! If you are getting notified of these specific students, you could add your custom tag to that student (as long as you have a filter in your population rule excluding test records which is one of our top recommendations), pulling that student into a query by Ref ID and forcing the rules to run. As long as that tag is being filtered out in your population rule, it should kick the student out of the population. You can then remove the tag, repeat your query and forcing of rules, and it should put the student back in the population starting back at Day 0. For these prospect/inquiry campaigns, it is best practice to include important information throughout the campaign and not just in certain emails, ie. links to the apply page, visit info, main webpage, etc. Make sure to sprinkle information throughout! Your population rules are your friend, so you can use them to get as specific or general as you please to capture the attention of those targeted audiences.

Hopefully, this is happening less and less with your applicant pool as they should have used a correct email on their application. However, you can also add a little bit of spice to some of your RFI forms with logic on the email address question. You can set up a filter that looks for emails that contain things like “.k12” or “.edu” or “district” or any of your common high school email domains. After they fill out the email question, if Slate reads any of those in the email address, you can set up a second question that says “hey it looks like you are using a school address. Would you like to provide a personal address so that we can make sure you do not miss any important information?” That could help cull the amount of non-delivered/bounces/etc as well for your team!

What are some resources you use for formatting emails that are received well to multiple types of emails (gmail, outlook, Yahoo) and are mobile-friendly? What type of code do you use? How do you format your buttons? Anything around making emails look better.

Our Creative team uses Stripo to develop our email templates and codes for buttons. Our Communications team also utilizes a proofing system, Email on Acid, to view how emails will appear on computer screens and mobile screens.

As a general rule, we strongly encourage having a media query in your html source code for your templates to accommodate for the mobile view. This media query basically states “if the screen is a maximum of 600 pixels wide, format everything like this…” This is why it is also important to have high quality images and set a standard for your templates.

As a note, Outlook is notorious for ignoring CSS styling, and Gmail will ignore stylized dark-mode color selections in the code and choose what color it deems best for dark-mode readers. For general coding help, we recommend W3Schools  or an AI tool like ChatGPT. You can copy/paste code into the AI tool and ask it “Can you help me make this mobile friendly” and it can help!

For visually appealing buttons, we love this color contrast checker.

Additionally, be sure to always have a back-up font listed in the “font-family” section of your html style code. You can have your favorite branded font, but if an email server or someone’s computer does not have that font available to read, the email server will most likely turn it all to Times New Roman. You can remedy this by finding the style tags and adding a comma then your second choice font then you could even go so far as to add a catch-all sans-serif before closing out the quotation marks again.

How to send an email in Deliver to all org contacts at all orgs that have at least one net deposited applicant for the specified term/round – in body of message include a table of all submitted applications for the specified term, listing their names, application status, deposit (decision) status as well as their final HS transcript (material) status.

You can use a Data Dictionary to capture this information and send it to counselors! Start your recipient list in the Configurable Joins – Organization Contacts base. To pull the student data and set up the Data Dictionary, create a subquery export. Keep your type as a dependent subquery, change your output to ‘Dictionary’. In the filters section of the subquery export, join from Organizations/Schools, Schools/Person, Person/Application Rank 1. Select your filters for application status or decision status of the student you want to share. Include a filter for ‘Schools/Rank By Level of Study’ to make sure you’re only contacting high school students. In the export section of the subquery export, pull in any export you want to pull into the email (decision status, material, etc). In the code of your email, you can follow the instructions for liquid looping to be able to pull the information into the body of your email!

Portals

How can I put a link to a person-scoped/user-security portal on a person record tab so that it auto-executes and opens the portal when you click on the link?

There are a couple of ways to approach this, but the most effective method is to create a new person-scoped tab and embed your portal within the form linked to that tab. To display person-specific data, you’ll need to pass query string parameters through the portal embed code in the form. In your portal query that pulls person data, remove the Portal Identity filter and replace it with a GUID filter using a parameter like @pid. Then, export the person GUID in the query and name it to match the parameter (e.g., pid). In the query’s Edit Parameters section, add <param id=”pid” type=”uniqueidentifier” /> and save. In the form associated with the person-scoped page tab, edit the form’s properties to include the person GUID as a merge field (e.g., {{guid}}) by joining to Person. Then, add an instructions block to the form and insert the portal embed link in the source code. In the script source (src) of the portal link, append &pid={{guid}}, where pid corresponds to your parameter and {{guid}} matches the merge field in your form. Once configured, the portal will automatically load with the correct data when the user clicks the tab on the person record.

Any recommendations for resources to learn script for those that don’t know CSS, HTML… to make Slating easier?

Utilizing AI services such as ChatGPT or BlackboxAI are a great tool to ask to provide the code needed and then learning how to read/break it down. Asking the prompts of “please create CSS code that does the following and then following it up with “please explain/break down what this means” is a very helpful tool to utilize. Codecademy, Khan Academy, and W3schools are free services to utilize as well to learn more about CSS and HTML. Conveniently, we also have a Slate Demo Series specific to Slate HTML.

How can I set up my portal so that a population of students is redirected to a different website?

To redirect a specific population in your portal, you’ll need to use a Redirect Query and configure a new method with the output type of Redirect. The redirect query should include an existence export to define which students meet your criteria (ie. if true add the link the population needs to be redirected to and the if false can be blank). Once saved, users who meet the filter conditions will automatically be redirected when accessing the portal. A step by step walkthrough of how to set up a portal redirect and multiple redirects is available in the Portal Redirects KB article.

How do you customize design elements of portals? For example, I know the CSS controls style but sometimes we would like two widgets next to each other and that requires changing the style to two columns, but then we want the content above and below to be back to one column. This is always complicated and never really looks quite right. Is there a way to easily do this?

Slate’s solution is the newer dynamic portal layout editor. This will allow you to pull in two rows with varying numbers of columns as needed. More advanced: CSS stands for Cascading Style Sheets. This means that there is an inherent hierarchy or priority for CSS rules. CSS rules can be declared for any combination of class, ID, and elements to target specific components on your webpage. If you’re struggling with your CSS making the changes you expect, you may have conflicting styles with either your instance branding or the Technolutions framework. To get better at understanding how pages are organized, especially for side-by-side content, take a look into flex box and grid display properties. There is a great learning tool called Flexbox Froggy which guides through the basics of flexbox. Additionally, the easiest way to set up side by side content would be to use Bootstrap’s column framework.

Why do my “default branding” portals run off the screen on mobile? How can you fix this?

This issue can be a bit tricky to troubleshoot because it usually means there’s an element on the page that’s wider than the screen. When that happens, any elements set to 100% width will expand to match the oversized content, causing the whole page to overflow and appear cut off on smaller screens. To resolve this, you’ll want to identify which element is causing the overflow. You can do this by inspecting the front end of the portal using your browser’s developer tools. Try switching to a mobile view and remove or hide elements one at a time to see which one is causing the issue. While I can’t say for certain without seeing your portal and branding, a common culprit is a heading element—like an H1—with a long word or large font size that doesn’t scale well on mobile, or an element on a form that has a fixed width that is larger than a small screen size In many cases, reducing the font size for smaller screens using responsive styles/media query can resolve the problem.

Student Success

1. We have a notes entity for advisors to enter notes after their advising appointments with students, but we can’t figure out how to pre-populate the advisor in the submitter field when they’re submitting the note. What are we missing?

2. When a person scoped form is submitted, you can trigger an email to go out immediately. I would like to have this happen on an entity widget form, but the communications tab is not available. How can I trigger an email to send instantly when an entity widget form is submitted? In this use case, the email going out hours later from a mailing is not sufficient.

Unfortunately you cannot use query-string parameters to pre-populate fields on an entity widget, which I’m assuming is the issue you’re running into.

How we typically get around this for a notes entity is by creating a person-scoped form, in addition to your entity widget, to collect note data. On the person-scoped form, you will map all of your note entity fields, including the user field you have for the submitter of the note, and then you can query-string in the system current user as the note submitter. The data collected on the form, because the fields are mapped to your entity, will all still write to the entity table and display with your notes widget.

I like to use a button on the student’s person dashboard, or in a faculty portal on a row of student data, as a place to house the query-string functionality and for faculty/staff to access student notes.

There are several places in our instance for student success where we’re querying on current term data, defaulting fields on forms to the current term, etc. Is there a way you’ve found to make that “current term” evergreen with maybe a formula or something so we don’t have to find all of those places to update during cycle prep at the end of each term?

My answer for this is one of my favorite Slate secret-menu-item hacks! In just about every term prompt list we build for student success we utilize prompt categories. The current term will have a category of “current” and you can also make the next term have a category of “upcoming” or “next”. This allows you to do cool things like:

• Query on if a student is registered for a course in an upcoming term by looking at all their courses for the existence of a term prompt with the “upcoming” category
• You can default the value of a term on a form to the “current” term so you don’t have to update the default to the actual term prompt each semester
• If you have a student schedule entity, you can automatically sort the student’s courses into separate widgets based on if the course has a term in the category of “current”, “upcoming” or “past”

This set-up also takes your cycle prep down to simply updating your term prompt categories at the end of each term, rather than having to hunt down every query and form where you’ve hardcoded a prompt value to “Spring 2025”.

Reports

My reports always time out. Do you have any tips or tricks to get them to run?

There are a few tricks you can use to help reports render a bit quicker. I always like to start by adding top filters to limit the data that Slate is processing in the report. If you are building a funnel YoY report for 2024 and 2025, consider popping in a top filter for 24 and 25 created applications as well as 24 and 25 prospects and inquiries. You can also add more filters at the row level as every bit helps with run time.

Another idea is to separate the report into different sections. I’d recommend utilizing subquery exports and filters when possible. Using global joins can slow down your report. Finally, if your report includes any formulas or custom SQL, just be aware that this can also impact performance and run time. Steer clear of those if possible!

Finally, let’s talk about reporting centers/portals. Displaying reports in a portal can improve load efficiency because portals allow for pre-filtering and scoped data loading based on the logged-in user’s context. Instead of running a large, static report that includes data for all users (which can be slow to load and process), a portal can generate a streamlined, scoped query only for the relevant individual or group (ie. match the user population to the applicant population).

What are the limitations of building reports in Slate? Can you replicate advanced reports that use multiple Excel Data sheets and or data charts that are manipulative like in an RNL portal, or is something like Power BI a better tool for that aspect?

While Slate offers robust reporting capabilities, there are some limitations when it comes to building advanced reports, especially for complex datasets. The primary challenges include:

Rendering Issues with Complex Reports: As reports grow more complex—particularly when they involve large datasets or intricate calculations—Slate’s built-in reporting tools may struggle to render them efficiently. This can result in delays or incomplete reports.

Limited Charting Functionality: The charting options in Slate’s reporting tool are relatively basic and less customizable compared to more advanced visualization tools. While you can use charts within reports, they often lack the level of interactivity and customization found in platforms like Data Explorer or external tools like Power BI.

Excel-Like Data Manipulation: Slate’s report builder allows you to treat columns (headers) and rows similarly to an Excel spreadsheet, which is useful for basic data presentation. However, the tool is more restrictive than Excel when it comes to manipulating or dynamically adjusting data. The setup is somewhat predefined, meaning you are limited to specific templates and configurations.

I am stumped on creating a line chart in reports with average wait times using two different time stamps. When I add fields for some reason it’s not allowing the X-axis data and then figuring out what formula I would use with date, and time stamp to get average.

To create a line chart with average wait times using two different time stamps, we recommend the following approach:

X-Axis Setup: For the row (X-axis), use the “Aggregate” row type. The function should be set to “Average,” and ensure the number format includes a “#” symbol to properly display the values.

Formula Integration: When working with multiple time stamps, you can leverage Slate’s export subquery feature. By adding the hashtag (“#”) in your formula, you’ll trigger preset formula examples that can guide you in setting up the necessary calculations. This will allow you to perform time-based calculations correctly.

Combining the Two Time Stamps: Finally, you’ll need to include both time stamp fields in your export. By adding these two exports to the chart setup, you’ll be able to calculate and display the average wait times across both time stamps.

Testing how best to create percentile bar chart in a report. I was able to get the correct numbers, but when I switched it to distribution for the chart, it only showed the whole numbers. I tried different Format Types, like REAL, but no luck. Is there a way to get 4.0, 3.9, 3.6, 3.2 and not 4, 4, 4, 3? Thanks!

Unfortunately, the “Distribution” chart functionality in Slate only supports whole numbers, so it’s not possible to display decimal values like 4.0, 3.9, 3.6, or 3.2 in the chart itself. This feature works well for data tables but is limited when applied to charts.

That being said, this could be a valuable feedback request to improve the flexibility of the charting feature in future updates.

Related question about reports – bar charts – instead of the counts/results shown in bubbles once hovered on the bar, is there a way to just show the counts without having to hover?

Unfortunately, there isn’t currently a way to display the counts directly on the bars in Slate’s charts without hovering. The counts only appear in the tooltips when you hover over the bars. This could be a great feedback request for future updates to improve chart interactivity.

I am trying to create a report showing speed-to-lead and am stumped on what the most computationally efficient way to do this is. My first thought was to create some subquery exports for the most recent RFI Form submission and first interaction logged after the submission date/time then compare. But I haven’t had any luck getting it to work. Any recommendations?

To calculate speed-to-lead, you can use the Comparison aggregate in the subquery export. This will allow you to compare whether the RFI form submission occurred before, after, or during the first interaction logged after the submission.

For the data table, set the row type to “Aggregate” and the function to “Average.” Then, apply the Date Difference formula, which will calculate the time difference between the two dates: one being the status/interaction code date and the other being the RFI form submission date.

This approach should help you efficiently compare and calculate speed to lead.

How may I create territory reports for the past 5 years by state? How may I access the school counselor information? How can I use Voyager effectively?

To create territory reports for the past 5 years by state, you can set up 5 columns – each representing one year of data. In the rows, use a subquery export and join the preferred geographics (such as rank 1 address or school address). Then, add exports for the region and include nested exports for geomarket or county as needed.

To access school counselor information, you will need to join the School and Organization tables and then link them to the Organization Contacts table.

As for using Voyager, the tool allows you to create markers based on individual queries. Voyager is designed to show you where students reside, as opposed to queries that reveal who the students are, and reports that provide insights on how many. By combining these features, you can gain a comprehensive understanding of your territory distribution.

Do you have any recommendations for Slate reporting on digital advertising work in Slate? What kind of ROI metrics could we access there? I’m thinking Ping is the best place to start?

Ping can be helpful for specific campaign reporting, as it uses similar UTM information as form submissions. Ping records don’t record on form pages unless they’re embedded on a website, so that’s only part of the picture, but it can be the quickest and easiest datapoint to gather. You’re still reliant on ping making those matches to the records, however.

Marketing data and ROI metrics is a great use case for a custom dataset and a related entity to attach to student records. With that custom dataset, you can provide any budget and goal related information for each campaign or medium, and tie full-funnel information from students attached to the entity when they are loaded via Facebook leads or set up as a Ping boomerang source format. You can provide the hidden fields on any forms as well to collect that data in every capacity. This would allow you to put a real dollar value on your marketing campaigns, directly in Slate.

Best Practices

I am new to SLATE. I would like to know what features are most useful for recruitment efforts.

We could easily devote an entire book to the topic, but if I had to give a “Top 5” for recruitment, I would say you should invest time into:

• Deliver. This is the main tool for communicating with your audiences. Everyone uses Deliver for emails, but devoting time to multi-channel communication (text messages, print pieces, and more) will be worth the effort.
• Events + Forms. Two separate modules, but they work together. You can also bring in the Deliver module to have a powerhouse combination, allowing you to effortlessly invite people to events, check them in, and follow up with them after.
• Portals. Whether for your events or your applicants to check what they are still missing (in addition to dozens of other functions) portals allow for highly customized, personalized content that mimics your website. Portals serve both a recruitment and a practical function and shouldn’t be skipped!
• Trips + Voyager. Also two modules. The Trips tool is for internally organizing recruitment travel, while Voyager creates geospatial maps for data points such as person status, school data, and more.
• Queries. This one is not specific to your recruitment, but everything in Slate, including the first four items on this list, rely on queries. You should devote some time to ensure your team is using configurable joins, and then explore all the options provided in the module such as aggregates and outputs. These make your life easier everywhere else in Slate.

I am a new Slate user and always get stuck with queries. Can you share any helpful tips?

We hear this a lot. As you may know, queries are arguably the most important feature in Slate and becoming proficient takes time. I would encourage approaching your learning in a few steps:

1. Conceptual understanding. It is important to understand how Slate is built, what it can do, and what it is not.
   At a high-level, Slate is a relational database, meaning that it stores data on a series of tables. Like an Excel spreadsheet with different tabs. We don’t need to get more technical than that. If you can even just take away that, for example, information about a person (such as their email address and birthdate) are stored in one place (table) in Slate and information about their applications or addresses is stored somewhere else, you are ahead of the curve. There is a tool in the Slate Database called the Configurable Joins Base Explorer that offers a schematic of how the tables relate. You might check that out!
2. Learning the nuances. Your office, department, and institution have nuances that make it different from other Slate instances. Spend some time getting familiar with your fields and prompts, for example. It is highly likely that you’ll be using the same few dozen options nearly all of the time.
3. Practice makes perfect. Go build! Specifically, build lots of quick queries (the ones that don’t auto-save) and learn by doing. What does that little button with the three dots do? What happens when I choose Citizenship (Primary) versus Citizenship Status? If you are simply adding filters and exports to a quick query, there is nothing you are going to break.
4. Consider additional resources. Recognize that querying is a journey and becoming an advanced query user can take years. Start small. One day at a time. As a final thought, I always recommend that learning queries in a group is a superb way to become proficient, and it can highlight that there are often multiple paths to an answer. Consider having a weekly meeting where you develop a query prompt or two and then everyone has some amount of time to figure it out. Then compare notes!

We are definitely not using Slate in its full capacity, and I am very new to Slate. Besides the basics, do any of you have your best practices for the application process? For example, we recently had someone build a portal for admitted students. They are now the rock star on our team! I want to be a rock star too. What are some cool tools or features I can introduce to my team?

Love this energy – and welcome to Slate! You’re in the perfect place to start building your Rock Star status. There’s so much to learn, and the Slate Knowledge Base is an awesome starting point. But honestly? The Community Forum, Slate Slack Group, and Slate Facebook Group is where the magic really happens. That’s where people share all the clever, quality-of-life things they’ve figured out – and it’s one of the best ways to learn what really works day-to-day.

Here are a few of our favorite quality-of-life things that can seriously level up your game:

• Reader Dashboards – Create custom views that make it easier for reviewers and staff to find and work through applications efficiently. These are made in portals but don’t let that intimidate you. They can be pretty darn straightforward and gives your readers a one-stop-shop for data while in the reader workflow
• Customized System Emails – This may sound a little simple but it’s one that’s easily overlooked since System Emails technically come out-of-the-box. Customizing, branding, and adding dynamic content (where you can) can really make the applicant’s process a lot easier. It also allows for them to immediately feel welcome the second they create an account.
• Conditional Logic – It’s already hard enough for applicants to apply to so many different schools – make it as easy as possible for them by using conditional logic, page keys, and existing data to ease their way through the process. Consider how you’re ordering the app pages to ensure that a question they answer in the first page could easily be used for conditional logic on the third page. Show them instructions and details that only they need to see. Use prompt logic to limit their selectable options. As you create the application, have non-Slate users test it and find where they get caught or are confused and use Slate’s functionality to ease their path. While this may seem basic, it can take time and expertise to get it right so test, test, test!

I’m a very new Slate user. I’m finding the Knowledge Base a bit overwhelming, and sometimes I’m not even sure what to search for or how to phrase my questions. What specific resource would you recommend for a beginner to learn the basics of Slate and build a strong foundation toward becoming an expert user? I need help with everything from getting my campus tour registration to work to setting up drip campaigns. Any insight you can share would be greatly appreciated. Thanks so much!

You’re asking all the right questions—seriously, this is *exactly* how you start becoming a power user in Slate. And yes, it can totally feel overwhelming at first, but there are so many ways to ease into it and build your skills over time. Here’s what we recommend:

Break It Into Chunks – Each step builds on the last

• Slate is modular—forms, events, communications, portals, etc.—so treat your learning the same way. For example, you might focus just on:
  • How forms work (with fields, rules, and visibility settings)
  • Then how events tie to those forms
  • Then how to connect those to emails or populations
• Community Conversations + Webinars = Gold
  • Keep showing up to webinars like this one! They’re designed for users just like you, and you’ll always pick up helpful terms, shortcuts, and ways to think about what’s possible. Community Conversations especially are great because you’ll hear real examples from peers doing similar things.
• Explore the Slate Showcase
  • Think of the Slate Showcase as a library of what’s possible – emails, portals, events, and more built by other institutions. One of the best ways to learn is to look at what someone else has done and reverse-engineer it. If you see a portal you like, peek at how it was built, copy the idea, and adapt it to your needs.
• Use the Community Forum When You’re Stuck
  • It’s not just for technical experts – it’s full of beginners asking exactly the kinds of questions you are. Even if you’re not sure what to search, just browse by topic (like “Events” or “Deliver”) and you’ll start picking up patterns. People are generous with templates, ideas, and advice.
• Know You’re Not Alone (and It’s Okay to Ask for Help)
  • Slate was built to be flexible – but that means there’s no single “right” way to do things, which is why teams like ours exist. Whether it’s through peers, consultants, or Community Conversations, the goal is to help you feel supported as you build confidence and knowledge.

You’re already doing what most people are afraid to do—asking questions and digging in. Keep showing up, keep experimenting, and keep it bite-sized. You’ll be surprised at how fast things start to click.

You asked for the toughest questions: RHB develops an SIS on top of Slate Admissions for a ~400-student university. Would Carnegie be able to one up RHB’s game by developing an SIS on Slate that will work for a ~3,000-student university while keeping the budget below a typical SIS implementation project with Workday, Ellucian, or Oracle?

The honest answer? As with all things Slate – It depends (though we have to admit that we would approach this as an independent situation and not one where we are building in response to something that worked for another partner institution or just to compete against our friends at RHB).

While you can – and maybe should – absolutely build out some SIS-like functionality in Slate, I wouldn’t recommend it as the right path for every institution. Slate was designed as a transactional CRM, not a long-term records system. That has real implications – like limited change tracking, performance considerations when data volumes grow, and the need to implement shorter-term data retention policies, which may not align with the archival needs of a true SIS.

To answer this question meaningfully, I think we’d first need to define what you mean by “SIS.” If you’re talking about enrollment records, basic term tracking, advising notes, and workflows for student support – those are areas where Slate can be extended pretty effectively, and we’ve helped institutions do just that. But if you’re expecting core registrar functionality like real-time registration, billing, degree audit, or transcript generation, those are better suited to platforms purpose-built for long-term academic records. We would also have to discuss the budget you are comparing this build against, as not all SIS implementations are priced the same, either.

We’d love to chat more and explore what’s realistic, what’s not, and what an alternative model could look like with Slate best practices and institutional benefits in mind! Reach out today to start a conversation.