Workflow & Tasks - Introduction

Overview

Workflow is a powerful feature that helps you plan and track the work needed to stay in compliance with organizational or regulatory process standards, while helping workers stay focused on the priorities that need their attention soonest. A workflow is a repeatable series of steps that define a business process; workflows are composed of steps, and each step contains one or more tasks that represent the actual work to be done.

Tasks work a little differently. While every workflow step contains tasks, tasks can also stand entirely on their own — you can create a task independent of any workflow directly on an intake report, case, or provider record to track ad hoc work.

In short, workflows route work to the right people at the right time based on a repeatable business process, while ad hoc tasks handle work that falls outside a repeatable process but still needs to be tracked or coordinated between staff or third parties on intake reports, cases, and providers. For example, a workflow might be built to reflect the process for licensing a new provider or for following up on an incident reported about a provider, while an ad hoc task might be something a case manager creates to make a one-off request — such as asking a client to upload a document that isn't normally required during onboarding.

Benefits

Using workflows & tasks in Casebook has a number of benefits:

• Keeps staff focused and organized — Workflows and tasks work together to help staff prioritize the right work, stay on schedule, and manage everything from internal process steps to client-facing milestones (appointments, resume workshops, trainings), so nothing falls through the cracks.
• Built-in guidance that shortens ramp-up time — Checklists and descriptions embedded directly in workflow steps and tasks give every user — especially new employees — clear direction on what to do and how, reducing reliance on scattered emails, spreadsheets, or side conversations.
• Predictable deadlines, coordinated in real time — Automatically calculated workflow deadlines combined with shared task visibility let teams coordinate care as it happens, work independently with confidence, and manage assignment and status from one centralized place.
• Audit-ready visibility into outcomes — Completed workflows and tasks live on the associated provider record, creating a detailed, reviewable history of decisions, files, and forms that supports compliance with regulations like HIPAA.
• Collaboration that extends beyond your team — Workflows define clear organizational expectations while tasks facilitate action-oriented collaboration with clients and referral providers, keeping everyone — internal and external — aligned toward shared goals.

Before You Begin

Before setting up workflows and tasks, take the time to:

• Understand how notifications work, since workflows and tasks rely on notifications to keep staff informed about new assignments, reviews, and approaching deadlines. Notification behavior for tasks and workflows is configured by an administrator in Admin, under a module's Notifications settings.
• Determine how you'll want to send work to your team and to customers — through repeatable, process-driven workflows, or through one-off assignments via manual (ad hoc) tasks.

Workflow Concepts

With workflows, you can:

• Define repeatable processes within your organization or unit.
• Identify for staff what their assigned responsibilities are.
• Incorporate a review process into assigned tasks.
• Target timelines to complete identified processes and tasks.

Workflows can cover the end-to-end process of what happens with a provider, case, or intake — or they can define a process that happens during the life cycle of a record.

Workflow Use Cases

Customers can create workflows for big, multi-step processes that trigger for every case or short, single-step, single-task processes that trigger under unique circumstances for a given intake report, case, etc. Either way, they’re a great way to provide process guidance to staff or ensure compliance with organizational policies/processes when necessary. Here are a few examples you could build in Admin:

• Someone contacts your agency and indicates they want to apply to be a child care center, and you create a provider record with the information gathered during that initial contact. A workflow for the licensing process is triggered by the provider type equaling “Child Care Center.”
• A licensed foster family reaches out and asks to work with your agency instead of their current supporting agency. A workflow for accepting a new resource family into the agency is manually turned on from the family's provider profile.
• A case is staffed, and a new attorney is listed as legal counsel. The Case Involvement Type = Legal Counsel trigger fires a workflow that generates tasks to send court documents and schedule a coordination meeting.
• A parent is added to a family reunification case with the role of Non-Custodial Parent. The trigger fires a workflow that creates tasks for notifying the parent of their rights and scheduling an initial family meeting.
• A screener adds the label “Priority Escalation” to an intake record after a hotline call describing immediate safety concerns. The Label Added trigger fires a workflow that notifies the on-call supervisor and creates an urgent field visit task due within 24 hours.
• A worker adds the label “Trauma-Informed Referral Needed” to an Engage case. The Label that was added triggers a workflow to identify and contact approved referral partners and track the outreach until a placement is confirmed.
• A supervisor updates the validity (end) date of a provider’s license. A workflow triggers 30 days before the validity end date to initiate a re-licensure process.

In each of these examples, the workflow fires automatically the moment the triggering event occurs — no manual activation is required. At the end of the workflow, the team has either completed the required process (a positive outcome) or documented why it could not be completed (a negative outcome).

How Workflows are Defined, Activated & Ended

Workflows are created, defined, and turned on in the Admin module. You can build workflows for use in Intake, Engage, or Track. Navigate the left-hand menu to find the “Workflows” section belonging to the relevant module.

Workflow Triggers & Activation

Workflows are triggered when data changes on a record. For example, a workflow can start automatically when:

• The status of an intake report or case changes from one value to another.
• A new service enrollment of a selected type is added to a service plan.
• A new person involvement is added to a case.
• A set number of days before or after a supported date field.
• A specific value is selected in a supported custom field.

Each time the configured event occurs, any workflow using that trigger will start automatically.

And, it is possible to link several triggers together where multiple conditions must be true for the workflow to trigger. You can have up to three conditions. Each time all trigger conditions are met by corresponding value changes meeting those conditions, a new workflow instance will be created. A special caveat about date-based triggers: if you choose a field like “last updated,” then each time the “last updated” field has a new value in it, and any other conditions are still met, a workflow instance configured as such will activate.

Workflows can also be activated manually by navigating to the Workflows section on an intake report, case, or provider record, clicking the plus sign, and adding the applicable workflow to that record.

Keep in mind that a workflow only triggers — automatically or from the manual list — if it is currently set to Active in Admin; inactive workflows won't appear as an option. Also be mindful of the field values you use to configure a trigger or an outcome: if that value is later archived or deleted from the system, it will cause the workflow to break.

Workflow Step Dynamics

Workflows are an assembly of steps and tasks. Steps occur in sequence, and a step can only be completed once its previous step is completed.

Steps are completed by the step assignee, while tasks are completed by individual task assignees — these can be the same person or different people. Step assignees and step reviewers are limited to full Casebook users, since other workflow features associated with step and reviewer assignees only apply to full Casebook users. Tasks, on the other hand, can be assigned to full Casebook users, non-Casebook users, and/or Portal users.

A step must have all of its required tasks completed or marked “skipped” before it becomes eligible to move to the next step. Any non-required task that a user doesn't explicitly mark as “skipped” will still be treated as skipped in the database for reporting purposes.

Step deadlines help keep staff aligned on due dates for an overall step and interface with the notification engine to send reminders about overdue steps when appropriate.

If a step requires an approval cycle, that approval must also be completed before the workflow can move forward.

Workflow Task Dynamics

Tasks represent the actual work that should be done within a step. When a step becomes active, all tasks in that step will be assigned and made available for completion. Tasks come in several varieties, which are covered later in this article - see the Task Concepts section.

Mark a task as required if it must be completed in order for a step to finish. Users can still skip required tasks, but only intentionally, and they must provide a comment explaining why. Optional tasks, by contrast, are automatically marked as skipped in the database if a user advances the step without completing them.

Tasks support a wide variety of routing options. For simple use cases, a task can route to a case's primary assignee. If you want a task to route to an external party, like a client, you can choose an option such as “one or more case people” — this means that when the workflow activates, whoever is responsible for the workflow on that specific case will choose the one or more people the task should route to (accomplished by the staff user doing final configuration of such tasks in the workflow viewer on a case after the workflow activates), since a single case in Casebook can have many people associated with it.

Organizations also have options for how a task's deadline is set. Nothing prevents a task deadline from conflicting with its step deadline, so if you need the two to align, be sure to configure the logic of each component to match the other.

Finally, for longer-running workflows, tasks can be set up to recur on a repeating basis. For example, a workflow that stays open for the duration of a multi-year case might include a task that recurs every six months to check in with the client on how things are going or record outcomes.

Workflow Closure

Ending a workflow can happen a few different ways:

• The final step assignee clicks the final “Submit Step” button from the workflow interface on the applicable intake report, case, or provider record, and no approvals are required. This ends the workflow with a “successful outcome” (discussed below).
• A user ends the workflow early by clicking “End Workflow”. This is noted on the workflow's record and is visible in reporting for any process analysis the organization wants to perform, and it ends the workflow with an “unsuccessful outcome” (discussed below).
• If the final step requires approval, the workflow ends with a “successful outcome” once all reviews are complete and “approved.” If a reviewer rejects the final step instead, that is treated as an “unsuccessful outcome.”

Defining Successful & Unsuccessful Outcomes

Workflow outcomes let you trigger other updates in the system depending on whether a workflow completed successfully or unsuccessfully. A workflow is considered “successful” when either the final step assignee submits the final step and no approval is required, or when the final step (configured to go through an approval/review process) is marked “approved” after the step assignee submits it for approval and all reviewers approve it.

A workflow is considered “unsuccessful” when it is ended via the “End Workflow” action at any point in its lifecycle, or when a final step going through review is marked as rejected.

Regardless of which event occurs, outcomes let the system automatically update values in other fields so your users don't have to remember to do so manually. For example, if a workflow completes for program onboarding, a case status could automatically move from “onboarding” to “receiving services,” if you configure the case status field to update that way.

How Step Approvals Work

Workflow step approvals let your organization require one or more reviewers to approve a workflow step via a sequential review process before work can continue. Workflow administrators determine:

• Whether a workflow step requires approval.
• Who reviews the step: Workflow administrators define who must review a step using dynamic assignments, such as routing an approval request to a specific role or team.
• The order in which reviewers complete their reviews.

If multiple people share a role or belong to a selected team, all of them will receive the approval request, and whoever completes the review task first satisfies the reviewer requirement for that step. If you want a step review to route to a single person, make sure that person is the only one in the assigned role or on the assigned team — or choose a different routing option, such as “supervisor of the primary assignee” (assuming the primary assignee has only one supervisor).

When a workflow reaches a review step, the assigned worker first completes all of the step's required tasks, submits the step for review, and the workflow moves into “In Review” status. The first reviewer then receives the approval request and either approves or rejects the step; if additional reviewers are configured, the next reviewer is notified in turn (if the first reviewer approves).

Once every reviewer has approved the step, the workflow automatically advances to the next step — or, if it was the final step, the workflow completes. If any reviewer rejects the step instead, the workflow returns to the step assignee so changes can be made before it is resubmitted for review.

Best Practice: Use a Separate Step for Work That Requires Approval

If a form or uploaded attachment needs to be reviewed and approved as part of a workflow, consider placing that task in its own workflow step. Workflow approvals happen at the step level, so separating the task makes it clear exactly what the reviewer is approving.

For example, if a form requires approval:

1. Create a workflow step that contains the Complete a Form task.
2. Assign the task to the person responsible for completing the form.
3. Add the appropriate reviewer(s) to the workflow step.
4. Once the assignee completes the form and submits the step, the assigned reviewer(s) are notified that the step is ready for review.
5. When the reviewer approves the step, the workflow moves forward to the next step.

Because the form is the only task within that step, approving the step effectively confirms that the completed form has been reviewed and approved.

Making Changes to Existing Workflows

At any time, a user can navigate to an existing workflow on an intake report, case, or provider record and add more tasks to an active step. These added tasks are almost like ad hoc tasks (described later), but remain affiliated with a workflow step — useful when a supervisor, or even a frontline staff user, needs to add more work to an in-progress workflow.

You can also change an overall workflow template if you need to, but those changes will only apply to new activations of the workflow — not to instances that are already completed or in progress. To edit a workflow template in Admin, you'll first need to deactivate the workflow; once your edits are saved, reactivate it so it can be triggered again.

Task Concepts

Users can assign a task to another Casebook user or to an external party in Intake, Engage, and Track. Tasks come in two varieties: ad hoc and workflow-driven. Ad hoc tasks are created in the Tasks section of a given intake report, case, or provider record. Workflow-driven tasks originate from a workflow the organization has set up to govern a process. Either way, all of your tasks — ad hoc or workflow-driven — appear together in the Tasks section for an intake report, case, or provider record.

Task Use Cases

A few examples of how tasks can simplify your day-to-day work:

• Organization A uses a team-based approach to case management. They use tasks on Engage to alert teammates to an item needing attention outside of the standard tasks created by workflows, letting teammates provide and track timelines for this supplemental work.
• Organization B needs to collect additional information from potential clients in a digitally secure manner. They use tasks on Intake to securely collect form submissions and uploaded files, and can even request a resubmission from a client if needed. These same kinds of tasks are available in workflow templates too, but because this information is non-standard, the organization requests it through ad hoc tasks on a case instead.
• Organization C uses a client-facing form to document case progress every 30 days. They use tasks on Engage to securely send these forms to clients for completion; once a client submits a response and staff accept it, the form is added to the record. This use case is probably easier to manage from within a workflow since it's repeatable, but it's included here to show that a process doesn't have to be driven by the workflow tool — you can run it through ad hoc task generation instead.

Using the Right Task Type

Casebook offers several task types, each suited to a different kind of work: simple confirmation tasks that something got done, tasks that require a form submission, and tasks that require an uploaded attachment. Choosing the right type up front means less back-and-forth once the task is assigned.

Basic Tasks

Basic tasks are simple action items you want other people — non-Casebook users, full users, and Provider/Client Portal users alike — to complete. They have very little functionality beyond being marked complete, whether through the Tasks table, a secure link for non-portal users, or the Tasks table on a Client/Portal user's or full user's dashboard. A basic task, when used in ad hoc (not workflow-driven) task creation, can be marked for “Review” if your organization requires the task creator to perform some kind of quality/approval check on the completed work.

Requires Form Tasks

This task type lets you easily and securely share forms created in Casebook with staff and third-party users. Casebook users, non-Casebook users, and Provider/Client Portal users can all complete forms this way, and completed forms are automatically saved back to wherever the task and form were created. Form tasks support the same reviewer capability as other task types when created in a non-workflow, ad hoc manner.

Shared vs. Individual Form Submissions

When assigning a Require Form task to an assignee option like One or More Case People or All Case People, you can determine whether participants work on a single shared form submission or receive their own individual submissions. This flexibility allows organizations to support both collaborative forms and forms that must be completed separately by each participant.

Shared Form Submission

Select the option to share one submission when multiple participants need to contribute to the same document.

For example, a family participating in a program may need to collaborate on a single family assessment.

Each person can contribute information to the same submission rather than completing separate forms.

Individual Form Submissions

Leave the shared-submission option unchecked when each participant needs their own completed form.

For example, an organization may require every adult participating in a program to complete an individual release of information.

Each person receives a separate submission, allowing their information and signatures to remain associated with their own form.

Continue Form Tasks

Understand “Require Form” vs. “Continue Form” Task Types

Continue Form task is a unique type of task that you can use in Workflow to allow multiple participants to contribute to the same form submission. Using two workflow task types, “Require Form” and “Continue Form”, your organization can determine who starts a form, who contributes additional information, and when each person should participate.

For example, a case manager can begin completing an assessment and save their progress. Later in the workflow, another participant can open that same form, review the information already entered, and complete their assigned portion.

This is accomplished by creating a “Requires Form” task to get a form started followed by any number of “Continue Form” tasks affiliated with the original “Requires Form” task.

The information entered by the first participant remains available, eliminating the need to start over or create duplicate submissions.

This capability is particularly useful for organizations that rely on collaboration between case managers, supervisors, clients, and other service providers.

Sequential vs. Simultaneous Completion of a “Continued” Form

Sequential completion allows participants to contribute to a form one after another. The key to this configuration is keeping each Require Form and subsequent Continue Form task in their own steps.

Each participant receives their task as the workflow progresses through its configured steps like this:

This configuration allows the case manager to begin the form before the participant contributes additional information. The supervisor can then review the form during a later step.

Simultaneous completion allows multiple participants to access the same form submission and be assigned tasks to edit it simultaneously

Each participant receives their task at the same time when the tasks are in the same step like this:

Both participants can access the existing submission during Step 2.

Important: Concurrent edits to a Form are not merged. If multiple participants are editing a Form at the same time, the last saved version takes precedence. This is why you may want to keep your Require Form task in one step and each subsequent Continue Form task in a subsequent step.

How Individual vs. Shared Form Submissions Work with “Continue” Tasks

When a Require Form task creates individual submissions, subsequent Continue Form tasks maintain those separate submissions as they move between participants.

For example, consider a workflow involving three case people and a case manager.

In this example, the case manager can work with the submissions before they are returned to the original participants.

When the workflow reaches the second Continue Form task, each case person receives only their own form submission, rather than access to everyone else's forms.

Shared Form set-ups are far simpler. Since the Form is shared, the same Form instance continues to move from task assignee to task assignee for however many Continue Form tasks a Require Form task has.

Complete a Continue Form Task

When a workflow reaches a Continue Form task, the assigned participant can access the form submission created by the earlier Require Form task. Previously saved information remains available. The participant can review existing responses, add information, or update fields as needed. This eliminates the need to create another submission or re-enter information that has already been collected.

Use Multiple Forms in One Workflow

Organizations can use Save & Continue with more than one form in the same workflow.

For example, a client onboarding workflow may require both an intake assessment and a service agreement. Each form can have its own Require Form task and associated Continue Form tasks.

Each Continue Form task references the submission associated with its corresponding Require Form task. This allows organizations to coordinate multiple forms throughout a workflow while keeping each submission connected to the appropriate tasks.

Requires Attachment Upload

This task type lets you quickly request that a staff or third-party user upload an attachment. When the assigned user navigates to their task list and opens this kind of task, they'll be prompted to upload the requested file(s). Uploaded attachments can also be marked for review (again, “task reviews” are available for ad hoc, not workflow-created tasks and are different from “step reviews,” which exist in workflows) and once approved, they appear in the record's Attachments section.

Update a Person Profile

The Update a Person Profile task type lets staff ask someone to update a person profile, either their own or that of another person involved in the case, intake report, or similar record.

When creating this task, staff choose two things:

• Subject: the person whose profile will be updated. Options are limited to people involved in the case, intake report, etc.
• Assignee: the person who receives the task and completes it. Options include other staff members and external recipients.

This task type works especially well with external recipients. For example, suppose a case includes one parent and two children. You can create three tasks, all assigned to the parent: one to update the parent's own profile, and one for each child's profile. If the parent uses the Client Portal, all three tasks appear on their dashboard, ready to complete.

 

Task Assignment Options

Tasks can be assigned to a variety of people (assignment options in the context of workflows are covered earlier in this article). For ad hoc tasks, users can choose from staff users, Portal users, or other people already in the system. When a task is assigned to a Portal user, it appears on that user's Portal dashboard; when it's assigned to a non-user person, the assignment is completed through a secure, email-based link. Staff can also invite a non-user person to become a Portal user directly while creating a task assignment.

Task Reviews

Task reviews work a bit differently than the step review/approval feature in workflows. If you mark a task for review, once the task assignee “completes” the task, the task is marked for review, and the notification are sent to the user who originally created the task.

Workflow-driven vs. Ad-Hoc Tasks

Viewing and managing tasks is covered in a separate article, but the key concept to take away here is that whether a task is created by a workflow or manually by a user, it's still just a task. You'll see a mix of workflow and ad hoc tasks on your home page, and when you navigate to an intake report, case, or provider record, the Tasks section shows both kinds together in one manageable, interactive table. If you only want to see workflow-affiliated tasks, you can open the workflow viewer for that workflow from the Workflow section of the record instead.

You can also add tasks directly to a workflow step if you want to note extra work completed under the umbrella of an ongoing workflow. That task, while ad hoc in nature, gives users a way to keep their work organized when that's something they want — or something organizational policy requires.