Slate Workflows do not natively support internal email notifications for queue assignments. However, similar functionality can be achieved using a Deliver mailing combined with a Configurable Joins-enabled query.
This approach allows institutions to notify users when they have items assigned to their queue—whether those items are:
Applications (Admissions)
Student alerts or cases (Student Success)
Prospects or engagement tasks (Advancement)
Dataset-driven records (e.g., requests, nominations, approvals)
Overview
This process sends one email per user per day, provided they meet the filter criteria, rather than sending one email per assigned record.
The solution uses:
A User-based recipient list query
Subquery filters and exports to evaluate queue assignments
A Deliver mailing to send notifications
The goal is to:
Identify users with items in their queue
Count how many items are assigned
Send a summary notification
Key Concept: One-to-Many Relationships in Slate
When building this solution, it is important to understand how relationships work in Slate.
A User may have many assigned records (applications, alerts, prospects, etc.)
Each individual record is typically associated with a single user at a time
Because of this:
Standard joins at the base query level will only return one related record
To evaluate all assigned records, you must use subquery filters and subquery exports
This applies regardless of the record type—applications, person records, or dataset records.
Building Configurable Joins
Step 1: Build the Recipient List Query
Create a query with a base of User.
Include standard exports such as:
User First Name
User Last Name
User Email
You will also create a custom export to return the count of assigned records in the user’s queue.
Step 2: Creating a Subquery Filter (Who Should Receive Notifications)
The subquery filter ensures that only users with assigned records in the relevant workflow bins receive notifications.
Edit the query and click the Subquery icon next to Filter.
Name the filter clearly (e.g., Users with Assigned Queue Items)
On the configuration window for the subquery filter, locate and click the Join button.
Note: This button works differently from the Join button on the base of the query because this button does not create a forced one-to-one relationship (only joining a single item of a one-to-many relationship). Instead, it joins all items in a one-to-many relationship in the filter. Join from User to Workflow Bin User Queue to access the queue of each individual user in the query.
Since each queue assignment is associated with a record in the user’s queue (one-to-one relationship), create a second join from Workflow Bin User Queue to Application. The applications in a Workflow and assigned to the user for review are now joined.
Make sure that the query is only selecting applications in the intended workflow for sending the notification by including a nested subquery filter (which means a subquery filter in a subquery filter) to ensure only applications in the desired Workflow Bins are selected. To do this, select the Subquery icon next to the Filter button in the Subquery Filter. This creates a nested subquery filter, which appears in a pop-up box over the initial one to indicate that it is one level deeper.
Give the nested subquery filter a descriptive Name.
Create a third join from application to Workflow Bin and filter for the desired Workflow Bins.
With the Aggregate of the subquery filter already set to Exists, save this filter to return to the original subquery filter. The original top-level subquery filter will return only users with an application in their Workflow Bin User Queue, where the application is currently in the selected Workflow Bins.
Step 3: Creating a Subquery Export
The last step to complete our recipient list is to create a subquery export to return the count of applications assigned to each User in the specified Workflow Bins. This process is similar to the previous steps' subquery filter. To create the subquery export:
Select the Subquery icon next to the Export button.
Give the subquery export a descriptive name to indicate the data intended to be returned.
A subquery export looks a lot like a subquery filter, but instead of having an Aggregate option, the export has Output options. The intention is to return a count, so select Aggregate from the Output list (to return numerical data about the potentially many applications assigned to each user) and select Count from the Aggregate list.
Create the same joins as previously done for the subquery filter, first from User to Workflow Bin User Queue and then from Workflow Bin User Queue to Application to return a count of applications.
To filter the applications to count only those in the specified Workflow Bin, create a nested subquery filter to join from Application to Workflow Bin, filter for bins previously selected in the subquery export , and set an Aggregate of Exists.
Once saved, the subquery export is now configured to return the count of applications in the user’s Workflow Bins User Queue that are in the selected Workflow Bins.
This subquery export can now be used, along with user email and any others you have selected, in the Deliver mailing.
With the recipient list set up, edit the Deliver message to set the User Email merge field as the recipient and include the App Count in Workflow Queue in the Example Bin merge field in the mailing content along with any other text the recipients should see.
Step 4: Configure the Deliver Mailing
With the query complete, configure your Deliver mailing:
Set User Email as the recipient
Include merge fields such as:
User First Name
Queue Item Count
Example messaging:
You currently have {{Queue Item Count}} items awaiting your review.
This can be adapted for different audiences:
Advisors → “student alerts”
Advancement staff → “prospects to review”
Staff → “requests requiring action”
Step 5: Schedule the Mailing
Set the mailing to Ongoing and configure deduplication based on your desired behavior:
Deduplication Options
Do not dedupe messages
Sends a message for every qualifying record
Send only one message per recipient
Sends only when new records are assigned
Allow recurring delivery
Sends at a defined interval (e.g., daily reminders while items remain in queue)
📖 Further reading: Deduping
Handling Deleted Records
When records (such as applications) are deleted, they may still exist in workflow queues.
To exclude deleted records:
In the subquery export/filter, add the "Person" join from "Applications" and a new subquery filter.
Name the subquery filter, set the Aggregate setting to "Exists", and add an export for the person GUID.
This prevents deleted records from triggering notifications.
Applying This Pattern Beyond Admissions
While this example references applications, the same approach can be applied to any workflow-driven process in Slate:
Student Success
Notify advisors of new alerts or cases
Send reminders for unresolved interventions
Advancement
Notify staff of prospects requiring review
Track engagement or stewardship workflows
Dataset-Driven Processes
Route and notify users about:
Internal requests
Event follow-ups
Institutional workflows