Workflow tasks

A workflow task represents an activity that is performed regularly for a case. As part of the case type, you define the workflow for the task. This workflow defines the sequence of steps or work items that must be completed for the task along with the role or user that must complete each step.

You specify that a workflow task is required for the case to complete or that it is optional. You also specify whether the task is started manually, automatically, or when a user adds the task in the Case Manager Client.

You can hide tasks from view in the case client. For example, if you have tasks that have no value to the case worker, you can mark those tasks as hidden when you design your solution. Typically hidden tasks are controlled programmatically through business logic that is built into the case management application.

You can mark a task to repeat when there is a property change or when there is a document filing precondition defined for the task. A task that is marked as repeatable can occur multiple times during the lifetime of the case in which it resides and can cause new tasks to be created and repeated. Task types can be restarted as needed to repeat, even if the task is already in complete state.

You can group predefined tasks by sets: all-inclusive or mutually exclusive. Adding tasks to an all-inclusive set means that all tasks in that set must be completed. Adding tasks to a mutually exclusive set means that if you start one task in the set, you cannot start any of the others. A task can be included in only one set type. A task that is included in a set must have a precondition.

To simplify a workflow, you can break a large task into smaller, more manageable tasks. For example, one task might be to process a loan request. You might break this large task into separate tasks for assembling the loan documents, reviewing the documents, and accepting or rejecting the request.

Generally, a case is not complete until all required tasks are completed or manually disabled, or any running task is completed or canceled. However, you can specify that some tasks don't affect whether a case is considered complete, and are automatically stopped when the case completes. For example, you can use this setting for a task that generates daily reports. When the case is completed, the reports are no longer needed and the task stops automatically.

Important: You cannot select the Stopped when the case completes and does not affect case completion setting for all tasks in the case. If this option is selected for all tasks in the case, the case never completes.

Required tasks

Workflow tasks that you make required for the case can be started automatically or manually as soon as the case is created or after preconditions are met for the task. For example, if the solution that you are designing is for credit card disputes and one of the case types is for claims with supporting documentation, you can create a required task for a claim review as soon as supporting documentation for a claim is added to the repository.

Optional tasks

Workflow tasks that make optional for the case can be started automatically, or manually as soon as the case is created or after preconditions are met for the task. For example, if the solution that you are designing is for automobile claims and one of the case types is for automobile accidents, you can create an optional task that can be manually started for the rental car task. Optional tasks are displayed second on the Tasks page.

Discretionary tasks

Workflow tasks that you make discretionary can be added by case workers as needed after a case is created. For example, if the solution that you are designing is for automobile claims and one of the case types is for automobile accidents, you can create a discretionary task to request that a field agent investigate the accident that is submitted by an insurance adjuster for possible fraud. Discretionary tasks are displayed last in the Tasks page.

Container tasks

You can define workflow tasks that contain other tasks, which are called subtasks. Container tasks can start automatically, manually, or discretionary. Subtasks are created after the container task starts. The subtasks within a container task cannot be discretionary. They can be only automatic or manual.

When you design a solution, you can create subtasks that start after the container task starts and the preconditions for the subtasks are met. For example, after a loan reaches the approved state, a bank might define two subtasks:

One subtask for notifying the customer of the loan approval.
One subtask for providing the funds to the loan applicant.

In this example, the loan process task is the container task that has the precondition of loanstatus=approved. The customer notification and funding tasks are subtasks that start only when the case property "loan status" for the loan case equals "approved".

If your administrator configured access to a business process management system, you can place FileNet® Business Process Manager and IBM® Business Process Manager Advanced subtasks inside of container tasks.

Subtasks

The subtasks that you create within a container task are created in Case Manager Client only after the container task that they are in moves to working state. You cannot mark subtasks as discretionary. However, you can move subtasks out of a container task, and then mark them as discretionary.