Chapter 1. Case management

Milestones are a special service task that can be configured in the case definition designer by adding the milestone node to the process designer palette. When creating a new case definition, a milestone configured as Adhoc autostart is included on the design palette by default. Newly created milestones are not set to Adhoc autostart by default.

Case management milestones generally occur at the end of a stage, but they can also be the result of achieving other milestones. A milestone always requires a condition to be defined in order to track progress. Milestones react to case file data when data is added to a case. A milestone represents a single point of achievement within the case instance. It can be used to flag certain events, which can be useful for Key Performance Indicator (KPI) tracking or identifying the tasks that are still to be completed.

Milestones can be in any of the following states during case execution:

While a milestone is available or completed it can be triggered manually by a signal or automatically if `Adhoc autostart`is configured when a case instance starts. Milestones can be triggered as many times as required, however, it is directly achieved when the condition is met.

A case instance is a single instance of a case definition and encapsulates the business context. All case instance data is stored in the case file, which is accessible to all process instances that might participate in the given case instance. Each case instance and its case file is completely isolated from the other cases. Only case instance participants can access the case file.

A case file is used in case management as a repository of data for the entire case instance. It contains all roles, the object, the data map, and any other data. The case can be closed and reopened at a later date with the same case file attached. A case instance can be closed at any time and does not require a specific resolution in order to be completed.

The case file can also include documentation in the form of embedded documentation, references, PDF attachments, web links, and other options.

In case management, comments facilitate collaboration within the case instance, and allow case workers to easily communicate with each other to exchange information.

Comments are bound to the case instance. Case instances are part of the case file, so you can use comments to take action on the instances. Basic text-based comments can have a complete operations set, similar to CRUD (create, read, update, and delete).

Case roles provide an additional layer of abstraction for user participation in case handling. Roles, users, and groups are used for different purposes in case management.

The following illustrates how the preceding case management concepts apply to a hotel reservation.

The role assignment (Guest) affects the specific work of the case and is unique to all case instances. The number of users or groups that can be assigned to a role is limited by the Case Cardinality, which is set during role creation in the process designer and case definition. For example, the hotel reservation case has only one guest while the IT_Orders sample project has two suppliers of IT hardware.

When the roles are defined, case management must ensure that these are not hard coded to single set of people or groups as part of case definition and that they can differ for each case instance. This is where case role assignments become important.

Role assignments can be assigned or removed when a case starts or at any time when a case is active. Although roles are optional, use roles in case definitions to maintain and organized workflow.

Roles are assigned to users or groups and authorized to perform tasks when a case instance is started.