Applications are processed through a defined series of steps using a workflow. This article describes considerations for creating additional workflows (and suggests ways to avoid creating them).
The standard workflow is accessed through the Reader in Slate. Most of the work on applications, including admission review, is done using the default Reader workflow. However, creating an additional workflow may be useful to include a secondary process that is separate from and simultaneous to the primary reading process.
The Slate Workflow Editor provides an all-in-one environment for creating and managing Reader workflows.
Example cases for an additional workflow
- A scholarship review where an application has a separate review process from its admission decision review process, occurring at any point during the primary reading process. Regardless of where the primary application is in process, the scholarship review process may take place simultaneously.
- An I-20 documents review where a different team reviews only the international documents, separate from the primary reading process.
Alternative methods to avoid creating workflows
For the sake of simplicity, consistency, transparency, and security, avoid creating additional workflows if reviews can be completed with the default workflow.
- For a scholarship review, where an application is reviewed for a scholarship after it has received an admission decision, the review would be an extension of the default workflow instead of a separate and simultaneous review.
- For an I-20 documents review, where documents are reviewed after an admission decision, but before final committee review. Adding a new bin to the existing default workflow in this case would be simpler.
Creating all the required components (Reader Bins, Reader Tab Groups, Reader Tab Materials, and Reader Review Forms) for each workflow can significantly increase complexity. Before deciding to create a new workflow, weigh the benefits of the added functionality against the increased complexity of multiple workflows.
Bins are organized into groupings and columns. Groupings are used to accommodate unique sub flows (For example, one for undergraduate applications and one for graduate applications) within the overall workflow definition. Often the overall workflow will only need one grouping, but customizing the workflow with sub flows may help match your business processes.
Within each grouping are columns to house the Reader bins and define the steps in the workflow.
Reader Bins illustrate your reading workflow within Slate. Each Reader Bin will contain applications that are in a distinct stage of your reading process.
Take the extra time to ask and answer your reading process questions and settle on the desired behavior for each bin in your structure to streamline the bin configuration process.
Do not get distracted with creating bin permissions when building your Reader resources. Focus on developing a clear and meaningful bin structure and save the custom permission work for later.
Make a Plan
Use sticky notes to imagine and strategize your bin structure with your office. Design a bin structure that is simple and useful for your basic application reading process. Do not design a bin structure that reflects reading processes that only happen occasionally (e.g., a Dean Special Hold bin).
For example, a school that has a Slate-hosted application may develop a Bin structure like this:
Develop a reader workflow that moves in the right direction. While applications might skip future bins (e.g., an application moves from the Read 1 bin directly to the Deny bin), your applications should never move backwards in your bin flow. For example, a sample application may take the following Reader bin path:
No Post-Decision Bins!
The Application Reader is for your reading process exclusively! Concluding your bin structure with clear and distinct decision bins will ensure a smooth decision release process.
Any post-decision activities are actions that happen after your reading process has ended and will employ resources within the student record view.
Discuss Reader Process & Strategy Bin-by-Bin
Once you have developed your bin structure on paper, move sequentially through your structure and determine the desired functionality for each specific bin. For example:
|Common Questions||Common Answers|
|When the review is complete, where should the application go next?||Admit or Deny or Waitlist|
|Should there be a default next bin?||No|
|Allow multiple readers to have the same application in their queues simultaneously?||No, this bin should only allow an application to be in one reader’s queue at a time.|
|Warn readers if they have previously read an application?||No Warning|
|Should the review be a blind read?||No, the previous reviewers should be visible.|
|Should this bin be locked?||No, readers should be allowed to manually add an application to their own queue.|
|Should this review be anonymous?||No, readers should be allowed to see the applicant’s name.|
|Should queue notification reminders be emailed to readers when applications in this bin are in their queues?||No|