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.

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 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 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.
• Another configured triggering event occurs on the record.

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

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 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.

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, available for ad hoc, not workflow-created tasks) and once approved, they appear in the record's Attachments section.

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.