Workflows provide a comprehensive tool for creating and managing review processes. Whether implementing an admission process in Slate for the first time or creating additional workflows for overlapping or distinct processes, it is crucial to break down the process occurring in each workflow.

Clearly establish the bounds of the review process (or processes) included in the workflow. Where does one process begin and another end? Records can be in multiple workflows at the same time, but they can only be in one bin for a given workflow. A person record can have multiple active applications associated with it, even within the same round; the applications are separate records that can simultaneously exist in the same application-scoped workflow. However, if a scholarship review or advisor-pairing process is concurrent with an admission review, they can (and likely should) take place in separate workflows.

Examples of Additional workflows

• Undergraduate and Graduate: A database is shared between undergraduate and graduate offices. The two offices require vastly different processes and have different sets of reviewers.

• 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 can take place simultaneously with another process.

• I-20 Review: An I-20 documents review, where a separate team reviews only the international documents, separate from the primary reading process. This occurs only for non-U.S. citizens after decisions have been assigned. 

Bin Structure

Bins illustrate the review process, and each should represent a particular step within the workflow. The movement from one bin to the next should be intentional, and the criteria should be clearly defined in either a bin movement rule or through expectations communicated to reviewers in bins where manual movement is necessary. 

Bins are stacked into columns that define the procedural steps in a workflow. Collectively, bins and columns form a grouping. Most workflows will only need one grouping, but additional groupings can accommodate unique sub-flows or sequential and mutually exclusive processes. 

Take the time to streamline the bin configuration process. Ask and answer your reading process questions, and then resolve the desired behavior for each bin in your structure. In most cases, bins should be kept generic and should pertain to stages of review, not who the record is or who the reviewers should be. Views can be configured and applied to all bins in a workflow to display only records that meet filter criteria for a special team of reviewers or for a program. An application can be reviewed by multiple parties in each bin, and different reader review forms can be conditionally shown based on applicant criteria. As a result, processes that require different numbers of reviewers per stage, or different reader review forms, may not need to be separated out across multiple bins. 

Make a Plan

Use sticky notes or a dry-erase board to visualize and strategize your bin structure with your office, and then recreate the structure in the Workflow editor. 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 (such as an Advancement Dean Special Hold bin).

For example, a school that has a Slate-hosted application might develop a bin structure like this:

The resulting Reader structure would look like this:

If you only accept applications from external sources or you do not need to view applications before they are completed, then an Awaiting Submission bin is not necessary. If the application fee must be paid before the application is received, an Awaiting Payment bin is not necessary. Reporting on these stages of pre-review is better done in the Reports tool. 

Bin Path

Most workflows should have a combination of automated and manual bin movements. Automated bin movements are most helpful when application completion is concerned in the early columns of the workflow. Once a manual review of the records has started, and bin movements are determined by reviewer discretion, automation should cease. 

Develop a reader workflow that moves records forward through the bins. Some records might skip bins or columns (for example, an application that moves from the Read 1 bin directly to the Deny bin), but applications should typically not be moved backward manually in the bin flow. That is, if a bin has automation associated with it, you should rely exclusively on the automation to move records into those bins. If a material is deemed insufficient to review that record, the material should be reclassified so that the applicant rolls back to Awaiting Materials. 

A sample application may take the following Reader bin path:

In special cases where a record's materials are technically sufficient to review, but additional follow-up is necessary, including "Hold" bins at various stages of the process can keep the actionable bins in the workflow clean. 

Testing the Review Process

Pay special attention to bins where applications are being reviewed. The Review Forms tab in the Workflow editor is helpful in visualizing which forms are used where, and the Summary tab allows for individual records to be run through reader review form criteria to determine the forms that will appear for them in which bin. 

The Bin & Queue Automations tab displays the exclusivity groups used within the reader. While building out, the rules can be dragged into the desired order, and the View Logic tab can run records through the exclusivity group to determine the bin a given record will be moved into automatically. Remember that, at a certain point, applicants in the workflow should not meet any rule criteria. 

Tab and Material Structure

The tabs to the left of the record organize and display applicant information, media, and materials. Tabs can appear based on individual record criteria, including the bin that the record is currently occupying. Different tab types can display links (URLs, embedded web pages, and Slate portals), Slate-hosted video essays or portfolios, or most frequently, clusters of materials and applicant data. One reader tab is often used to host a Dashboard overview of each record that appears in the workflow, in the form of a Reader Portal Dashboard. 

When planning tabs, the name that appears should be helpful and informative to a reviewer and should correspond to the type of information being displayed, rather than to the current stage of the workflow or bin for the applicant. What are the categories of materials viewed? How do they parallel the flow of questions and fields on reader review forms? 

The materials in reader tabs, including a Dashboard, are there to be reviewed. Additional information can be added to the record through reader review forms or material metadata. 

Tabs can have custom read permissions applied and can be excluded for certain users, but the individual Material Stream Types within them cannot be. If building a workflow where some materials must be omitted entirely based on permissions, add the permissions necessary at the tab level.