Migrating from Reader (Legacy) to Workflows is an opportunity to review how records move through your review process before you rebuild the configuration. Use the migration to keep the parts of your current process that work, remove unnecessary complexity, and decide how Workflows should support your readers.
Expect to rebuild most Workflow-specific configuration, including bins, rules, and views. Reader Review Forms and Reader Portals may not need to be rebuilt, but you should verify their workflow associations, visibility rules, and reader experience as part of testing.
⭐ Get Inspired
This article was adapted from a post by Technolutions staff in the Slate Community Forums' Get Inspired space. Have a great idea for a Get Inspired post? Let us know!
Planning the migration
Start with a planning phase before creating the new workflow. Review the current Reader (Legacy) process and decide what should stay the same, what should change, and what can be removed.
Inventory the following parts of the current process:
Reader bins, columns, groupings, and next-bin behavior.
Reader rules and bin movement automation.
Reader Review Forms and the bins where each form appears.
Reader tabs, Reader Tab Materials, and any portals embedded in the Reader.
Preset queries, saved filters, and report queries that reference Reader (Legacy) data.
Admin PDF or Application PDF download options.
Custom permissions that control who can view bins, move records, or review records.
After you inventory the current process, map the new workflow structure. In most cases, bins should represent review stages, not specific reader populations. Use views, filters, review form criteria, and permissions to support special reviewer groups or program-specific needs.
Designing the bin path
Build a bin path that moves records forward through the review process. Most workflows use a combination of automated and manual movement. Automated movement is usually most useful early in the workflow, where record criteria can determine whether a record is ready for review. Once reader judgment determines the next step, manual movement is usually clearer.
As you design the bin path:
Keep the primary review path simple and easy to explain.
Avoid creating separate bins for occasional exceptions when views, filters, or reader form criteria can support the same need.
Plan whether records can skip future bins when they meet specific criteria.
Avoid manually moving records backward through a bin path that depends on automation.
Building and testing the workflow
Create and test the workflow with an Active status. Inactive workflows can create errors and can require reader tabs to be rebuilt. To keep the workflow hidden while you build, apply a Custom Read Permission and assign that permission only to users who should test the workflow.
Records can be part of more than one workflow at the same time. This means you can build and test the new workflow while your active review process continues in Reader (Legacy). Use this overlap to compare bin movement, view behavior, tab visibility, and reader navigation before you transition users.
When building the workflow, review the following areas:
Bins: Recreate the planned groupings, columns, bins, and default views.
Views: Replace Reader preset queries with workflow views. Configure default or shared views where readers need consistent columns, filters, or sorts.
Reader Review Forms: Confirm which forms should appear in each bin and test conditional form criteria.
Reader tabs and materials: Recreate tab visibility and material display in the new workflow.
Permissions: Test custom read and move permissions with users who should and should not have access.
Managing bin and queue automation
Review automation carefully before moving readers into the new workflow. Bin and queue automation can change a record's workflow placement when the rules run. If the workflow uses exclusivity groups, make sure the filters account for higher-priority rules that a record may meet.
If records should keep an existing queue assignment, add criteria or a Do Nothing rule to protect records that already have a current queue assignment. Test queue assignment scenarios before opening the workflow to reviewers.
The Review Forms, Summary, Bin & Queue Automations, and View Logic areas in the workflow editor can help you confirm which forms appear, which rules apply, and where records move during testing.
Updating queries and reports
Reader (Legacy) and Workflows store review data differently. Reader (Legacy) supported one primary review process for an application. Workflows can place a record in multiple review processes at the same time, so legacy Reader joins may not return Workflow Editor data.
📝 Note
Do not use legacy Application joins such as Current Bin, Bin History, or Application Reader Queue when querying data from workflows created in the Workflow Editor. Use workflow-specific joins instead.
Review and update reports, rules, exports, and reader views that reference Reader (Legacy) data. For application-scoped workflows, rules created in the Workflow Editor use the Configurable Joins - Application query base. To filter for workflow bins, join to Workflow Record: [Workflow Name] and then select the relevant bins.
📖 Getting Started with Configurable Joins
Common workflow joins
Workflow: Returns workflow-level configuration, such as the workflow name and status. Use it when you need to filter or display the workflow itself.
Workflow Bin: Returns records that are currently in workflow bins. Use it when you need current bin placement.
Workflow Bin History: Returns historical bin entries, including when a record entered and exited a bin. Use it for reporting on where a record has been.
Workflow Bin User Queue: Returns records that are currently assigned to user queues. A record can appear in more than one user queue.
Workflow Bin User History: Returns historical user queue entries, including when a record entered and exited a user's queue.
Workflow Records: [Workflow Name]: Returns records currently in a specific workflow. In Reader tab, material, and review form filters, this base is often the starting point before joining to Application, Person, or Dataset Record data.
Reviewing PDF and material display
If your process uses Admin PDFs or Application PDFs, review the Admin & Applicant PDF Download Options configuration. These download options are still configured with Reader Tab Groups and Reader Tab Materials.
For data that should appear inside the workflow reader experience, use Data Containers. Data Containers can display mapped application data, data from custom widgets, related records, and documents with filters and sorts that match the workflow review process.
Migration checklist
Inventory the Reader (Legacy) configuration that supports the current process.
Map the new workflow structure, including groupings, columns, bins, and expected movement.
Decide which movement should be automated and which movement should be manual.
Create the workflow with an Active status and limit access with a Custom Read Permission while testing.
Rebuild bins, views, reader tabs, materials, and automation in the workflow.
Confirm Reader Review Form visibility and submission behavior in each relevant bin.
Update reports, views, rules, and exports that use Reader (Legacy) joins.
Review Admin PDF and Application PDF download options.
Test the workflow with records that represent common and exception scenarios.
Validate permissions and the reader experience before directing users to the new workflow.