Workflows are a powerful tool for managing review processes in Slate. Separating distinct processes into separate workflows often means easier management, maintenance, and reporting.

Before you begin

Break down the steps involved in each process before you start working in Slate. Clearly establish the boundaries of the review process or processes included in the workflow.

Consider where one process begins and another ends. Records can participate in multiple workflows at the same time, but within a single workflow, a record can only exist in one bin at a time. This is an important concept when planning how processes should be organized.

For example, a person record can be associated with multiple active applications, even in the same round. Each application is a separate record, and those records can exist within the same application-scoped workflow. But if one of your processes, like scholarship review or advisor pairing, occurs alongside admission review, you should probably represent those processes with separate workflows.

Examples of workflow separation

Here are some situations where you’d want separate workflows:

Undergraduate and graduate

Your database might be shared between your institution’s undergraduate and graduate offices. In many institutions, these offices use entirely different review processes and involve different sets of reviewers.

Creating separate workflows grad and undergrad workflows lets each office manage its own process without interfering with the other.

Scholarship review

A scholarship review might require its own evaluation process that’s separate from the primary admission decision review.

In this scenario, an application can enter a scholarship review workflow at any point during the primary reading process. Because workflows operate independently, this scholarship review happens simultaneously to the application moving through the admission review workflow.

I-20 review

An I-20 document review may require a separate team to verify international student documentation.

This review process typically occurs after an admission decision has been assigned and applies only to non-U.S. citizens. Creating a separate workflow allows this team to manage document verification without affecting the primary application review process.

Designing your workflow bins

A thoughtful bin structure makes the workflow easier to manage, easier for reviewers to understand, and easier to maintain over time.

Some guidelines:

• Bins are stages of review. Bins are most flexible and useful when they represent steps in the process, rather than the type of record or the identity of the reviewer.

• Don’t make separate bins for separate reviewer groups. Instead, filter records with views: each reviewer or team sees only those records relevant to them in a given stage of the process.

• Use conditional reader review forms. Rather than making bins for every review need, use conditional logic to display the right form to the right reviewer based on criteria like program, population, or application attributes.

• Keep the total number of bins small. Having fewer, well-defined stages is easier to follow and reduces the likelihood of confusion or incorrect movement.

• Clearly define how records move between bins. Movement should either be automated through bin movement rules or supported by clear reviewer expectations when manual movement is required.

• Plan for the long haul. Build your workflows with reporting and long-term maintenance in mind. A streamlined bin structure makes it easier to track progress, analyze workflow activity, and adjust processes in the future without needing to rebuild the workflow.

• Don’t worry about edge cases. Design a bin structure that supports the application reading process that’s used most of the time. Avoid creating bins that represent rare or exceptional situations, like the occasional administrative hold or special-case reviews. Processes that occur infrequently can often be handled through other workflow tools and don’t requiring additional bins.

With these in mind, use a visualizer tool, sticky notes, or your trusty office whiteboard to visualize bin structure with your team before building it in Slate. This exercise helps you clearly map each step in the process and determine how records should move through the workflow.

A typical school using the Slate-hosted application might set up their bins like this:

*Omit if you only accept apps from external source

**Omit if you collect payments before receiving apps

Moving records through the workflow

Now that we’ve got an idea for the different stages it’s possible for a record to pass through, we can start working on the movement from one bin to another. Most workflows should include a combination of automated and manual bin movements.

Automated bin movements are particularly useful in the early stages of a workflow, where application completion determines whether a record can move forward. Automation can efficiently move records through initial bins as materials are received and requirements are satisfied. Once manual review begins and bin movement decisions rely on reviewer judgment, automation should typically stop.

Plan for records to move forward through the bin structure as they progress through the review process. In some cases, records may skip certain bins or columns. For example, an application may move from Read 1 directly to Deny if the reviewer determines that no further review is necessary.

In general, records should not be manually moved backward through the workflow. If a bin relies on automation to move records forward, it is best to rely exclusively on that automation rather than manually adjusting placement. For example, if a required material is later determined to be insufficient for review, the material itself should be reclassified so that the applicant is automatically returned to an Awaiting Materials stage.

An application might follow a bin path in our example bin structure like so:

💡 Tip

In special cases, when 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. 

Post-decision bins in an application review process

Ending your bin structure with clearly defined decision bins helps ensure a smooth and organized decision release process. Once an application has reached a final decision bin, it has completed the review process within the workflow.

Workflows should not be used solely to store or view applications after decisions have been released. If your goal is to review or analyze released decisions, create a report.

Post-decision activities typically occur after the reading process has concluded and are often managed through tools available in the student record view. For this reason, workflows should focus on representing the stages of the review process itself rather than attempting to capture the entire lifecycle of an application.

Design your workflow to clearly reflect how applications move through review, ending with the assignment of a final decision.

Testing the review process

As you build a workflow, test the way records move through the review process. Pay particular attention to the bins where applications are actively being reviewed to ensure that forms, rules, and automations behave as expected.

• The Review Forms tab in Workflows can help visualize which reader review forms are available in each bin.

• The Summary tab can then be used to run individual records through the reader review form criteria to confirm which forms will appear for that record in a given bin.

• The Bin & Queue Automations tab displays the exclusivity groups used to determine automated bin movement. While configuring these rules, you can drag and reorder them to reflect the desired evaluation order.

• The View Logic tab lets you test records against an exclusivity group to determine which rule will apply and which bin the record will move into automatically.
  

There should typically be a point in the process where records no longer meet any automation rules. At that stage, bin movement should be controlled by reviewer action, rather than automation.

Tabs and materials

The tabs at left in the Reader present applicant information, materials, and media to reviewers. Tabs can appear based on criteria related to the record itself, including the bin the record currently occupies within the workflow.

📖 Reader tabs

Different tab types can display a variety of content. Tabs may include links such as URLs, embedded web pages, or Slate portals. They can also display Slate-hosted video essays or portfolios. Most commonly, tabs contain clusters of applicant materials and data that reviewers need during the evaluation process.

Many workflows include a tab that provides a high-level applicant dashboard. This Reader Portal Dashboard is often used as the first tab reviewers see when opening a record in the workflow.

When planning reader tabs, the tab name should be clear and informative for reviewers. Tabs should generally be named based on the type of information they contain rather than the stage of the workflow or the bin the applicant occupies. Consider how reviewers interact with the materials: what categories of information do they need to review, and how do those categories align with the questions and fields presented on reader review forms?

The materials displayed within reader tabs, including those shown on a dashboard, are intended to be reviewed rather than edited. If additional information needs to be added to the record during review, it should typically be captured through review forms or through material metadata.

Tabs can also have custom read permissions applied and can be excluded for certain users. However, permissions cannot be set at the individual Material Stream Type level within a tab. If a workflow requires certain materials to be hidden from specific users, the necessary permissions should be applied at the tab level.