This article contains dated content. Please refer to the new Planning Workflows article for the most up-to-date information.
Applications are processed through a defined series of steps using a workflow. This article describes considerations for creating additional workflows.
Most of the work on applications, including admission review, is done using workflows. However, creating additional workflows may be useful to include a secondary process that is separate from and simultaneous to the primary reading process.
Workflows provide an all-in-one environment for creating and managing the entire reader process.
Example Additional workflows
- Shared Database - A database is shared between undergraduate and graduate offices. The two offices require vastly different processes.
- Scholarship Review - 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.
- I-20 Review - An I-20 documents review where a different team reviews only the international documents, separate from the primary reading process.
Alternative to Additional Workflows
While it is possible to create multiple workflows for varying offices' needs, creating multiple workflows also means maintaining all of the required components that come along with a workflow such as bins, automation, tabs, review forms, views, etc. resulting in a potential increase complexity.
- Scholarship Review - 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 single workflow instead of a separate and simultaneous review.
- I-20 Review - For an I-20 documents review, where documents are reviewed after an admission decision, but before the final committee review. Adding a new single bin to the existing default workflow, in this case, would be simpler.
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.
Bins illustrate your workflow within Slate. Each 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 by 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 backward 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 Process & Strategy
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:
|When the review is complete, where should the application go next?
|Admit or Deny or Waitlist
|Should there be a default next bin?
|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?
|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?