As show above, in DCM a case is a concept that combines many other concepts. We do not aim to give one precise definition of a case in this document, but try to explain which concepts can play a role when designing a case. One misunderstanding can be corrected upfront: a case is not just a process or an instance of a process. A case is way more than that.
All concepts in the image above are briefly discussed below.
A case always has a goal, this is most likely singular. In order to reach that goal, many concepts play a role. For instance decisions are made, in one or more processes. Furthermore, a case goes through phases, where a phase change is achieved formally by means of reaching or crossing a milestone. A case can have different states, even more than one simultaneously. Data is persisted in a case and a case can use data from outside sources, such as a register. Within cases, tasks can be performed, even outside of the scope of the main process. Such tasks are part of the case definition as well. Cases may relate to other cases or can be hierarchical. In some domains, a risk profile is used to determine whether additional checks are needed. Notes and appointments are part of the case definition and are probably available throughout the life cycle of a case. Events can lead to actions that need to be performed in a case. Cases will most likely contain uploaded documents and will generate documents themselves as well. Cases are all about collaboration; people can be involved and teams, organizations and roles can be defined to execute parts of the processes within a case. Time management is almost always relevant, since law and legislation state maximum durations, for instance for deciding on an application. Finally, history is an important aspect of a case as well; it is necessary to see who did what when.
All afore mentioned concepts contribute to a case, but that does not mean that each case has to consist of all these concepts necessarily. However, most (or even all?) cases contain decisions, will have at least one process and will most likely store some data and/or produce a document.
Blueriq concept of a case
With Blueriq's proposition of Dynamic Case Management, many DCM concepts are available within the Blueriq software platform. However, not all concepts can be found in Blueriq as a standard out-of-the-box concept. Shown below is the same diagram as above, containing a case and all its related concepts. The concepts in blue deviate from the previous diagram; this means that the DCM concept itself is not available within Blueriq as such, but one or more Blueriq concepts can be used to model the DCM concept effectively, completely and correctly.
In the diagram above, all pink concepts are DCM concepts that are part of Blueriq by default. The concept of a decision is one of the most dominant ones, but also processes, persistency by means of aggregates and output documents are used in many - if not all - Blueriq applications. Teams and roles may not be as common as decisions, but are used very frequently.
The blue concepts in the diagram above indicate DCM concepts that are not available within the platform as a standard Blueriq module element, but can be modeled using out-of-the-box Blueriq functionality. For instance, the goal of a case, milestones and states; they can all be modeled using decisions, most likely decision tables or business rules. Notes and incoming documents can be modeled using specific containers. For triggers, incoming message events can be used. Appointments, involvements and organizations can be modeled with attributes.
The most protruding blue icons are that of the case itself and related cases; aggregates are used to model cases. This means that not only standard persistency by means of registers is done using aggregates, but also the case itself is an aggregate!
Comparison
The table below compares all DCM concepts with Blueriq concepts and briefly explains how standard Blueriq concepts can be used to model the DCM concept.
Concept in DCM | Concept in Blueriq | Remarks | ||
---|---|---|---|---|
Case | Aggregate | A case is modeled as an aggregate, meaning that for each case an aggregate is defined, containing all entities necessary to define a case. See also Designing cases using aggregates [editor]. | ||
Goal | Decision | The goal of a case could be to grant a permit, register an applicant, pay a benefit, sell a product etc. A goal can easily be modeled by an attribute with a default value false and a decision table or business rule which sets the attribute to true when the goal is reached. | ||
Decision | Decision | The concept Decision is available in Blueriq. | ||
Process | Process | The concept Process is available in Blueriq. | ||
Milestone | Decision | Whether a milestone is reached or not is a decision, based on the context of the case. For more information on how to model milestones in DCM applications, see Designing dynamic processes. | ||
Phase | Process | With phases, a case can be broken down in large concepts, using the lowest granularity. Most cases consist of five plus or minus two phases. All phases are modeled as processes and since processes can be modeled hierarchically within Blueriq, the main process itself, containing the phases, is modeled as a process as well. For more information on how to model phases in DCM applications, see Designing dynamic processes. | ||
State | Decision | A state is a characteristic of a case that tells the end user not so much about the progress of the execution of the case over time (phases are used for that), but more about the progress regarding the case's identity. For instance, a case can have the state In progress. This does not really tell us how far we are, merely to be patient. Another example of a state is Waiting for customer, when additional data or documents are needed. States can be plural on occasion, so a case could be in two states, for instance Part of spot check and Confidential. | ||
Data | Aggregate | For persistency of data, aggregates are used. See also Persistency Management guide. | ||
Task | Task | Tasks are standard Blueriq functionality. | ||
Related case | Aggregate | Related cases are modeled as aggregates, just like the case itself. The relation between the related case and the main case is modeled as an attribute within the related case, containing the Id of the main case. The type of relation (parent-child, sibling, association, etc) can also be modeled using attributes. These relation-attributes are most likely part of a Case data or Control entity, but this is the designer's choice. | ||
Risk profile | Decision | A risk profile or risk calculation can be performed with decisions and sub-decisions perfectly, using potentially many attributes of the case. | ||
Note | Dashboard Comment container | Notes are modeled with a dashboard comment container. By default, the comments are multivalued and date-time and user are stored alongside the comment. | ||
Appointment | Attribute(s) | To model an appointment within a case, the best fit is to use attributes of an Appointment or Control entity. For the integration with a calender (for instance Google calender or Outlook), tailored software has to be bought or developed, since this is not available in Blueriq out-of-the-box. | ||
Event | Incoming external message | Events are situations form outside the case that require actions to be taken withing the case. For instance the death of the applicant could require the case to cancel, or the divorce of an applicant could result in recalculation of a fee. In Blueriq, events are modeled as in incoming external messages. For an example of an incoming external message, see Designing dynamic processes. | ||
Document input | File upload container | File management is an integral part of Blueriq. Containers are available to upload and download documents to memory or the file system. Documents that are input for the case and need to be uploaded within the case, use the file upload container for that. | ||
Document output | Document | The concept Output document is available in Blueriq. | ||
Involvement | Attribute(s) | Involving persons in a case is not part of standard Blueriq functionality, but can easily be modeled using one or more (multivalued) attributes, most likely as part of an Involvement entity, but this is up to the designer. To involve someone in a case, for instance the applicant or the case handler or investigator, means setting an attribute with the desired involvement. | ||
Team | Team | The concept Team is available in Blueriq. | ||
Organization | Attribute(s) | Organizations strongly resemble teams, but the concept itself is not available in Blueriq by default. Therefore, organizations can be modeled using one or more (multivalued) attributes, most likely part of an Organization entity, but this is up to the designer. To rout a case to an organization, means setting an attribute with the desired organization. | ||
Role | Role | The concept Role is available in Blueriq. | ||
Time management | Time management | The concept Time management is available in Blueriq. | ||
History | Time line container | The concept History is available in Blueriq by means of a time line container. |
The generic case aggregate
Since all cases can be modeled as aggregates, one might wonder what such an aggregate would look like. Are they completely different for each case or is there a common ground among all cases? The answer is the latter; aggregates that resemble cases all look alike. Shown below is the outline of such a generic case aggregate.
Entities in the case aggregate
The table below briefly explains each entity within the generic case aggregate.
Entity | Explanation |
---|---|
Case data | All data that is relevant within the case can be part of this entity. For example, in a case for an application for a permit to extend a house, all attributes of the application itself are case data, as well as the case handlers and relevant dates. |
Case metadata | All metadata of a case can be combined in this entity. Example attributes are creation date, archive date, type, Id etc. |
Precondition | Activities in a dynamic case are not modeled as part of a flow with gateways and arrows, but as ad hoc tasks with preconditions that tell when the activities may be performed (see also Designing dynamic processes). For purposes of understandability, insight and oversight, it is best to combine all preconditions of a case and make them part of one entity. |
Milestone | For each phase within the case, a milestone tells whether the phase is complete and the next phase may begin. This entity contains an attribute for each milestone. |
Primary Decision | The primary decisions of a case can be combined in this entity. Examples are whether an application is complete or granted, or whether a spot check needs to be performed etc. The goal of a case will most likely be part of this entity as well. |
Time management | Time management or time monitoring can be part of the case when there are legal and/or legislative terms which must be complied with, such as a maximum amount of time in which an application has to be handled. Attributes used in this entity could be the terms themselves, but also the actual time that was needed. |
Risk profile | A risk profile entity can be used when a certain permit, benefit or insurance may not be granted unconditionally, but is subject to for instance an audit or a two-men-rule, should the application pose a risk. Risk calculation could then be done using attributes throughout the case, the (intermediate results and) final result of such calculations should be part of this entity. |
Norm | Norms are guidelines that are administered by law. People have to abide to the law, so they have to abide to or comply with the norms that are set within the law. For example, in an application case for a permit to extend a house, one has to comply with the norm that states that the additional surface of the extension is not more than a certain percentage of the surface of the original house. |
Ground | Grounds are usually intermediate results, decided or calculated because of specific articles of the law. Examples are the ground for tax on employment income, franchises or calculated income on which pension is based. But also the surface of the intended extension of a house (as mentioned in the previous row) could be regarded as a ground and can be used to test whether a norm is complied with or not. |
Constant | When there are constants in the domain of the case, it could be the designer's choice to explicitly model them as attributes of a constant entity. An example of such a constant could be the percentage that is used as a maximum regarding building extensions (as mentioned in the two previous rows). For more information regarding constants, see the chapter Constants of the Decision Management guide. |
Document | With file management, it is advised to use a multiton entity to create an instance for each document that is part of the application or the case. Such an entity contains metadata attributes like name, size, type, creationdate, etc. |
Involvement | Involvements are modeled by means of a multiton entity, possibly containing attributes such as Id, role and name and from when to when (phase or date) someone was involved in the case. |
Organization | When organizations are part of the case, the routing behavior as available for teams must be mimicked for organizations using this multiton entity. Additional tailored software needs to be developed to integrate teams in Blueriq's out-of-the-box routing mechanism. |
Appointment | When appointments are part of the case, this multiton entity can be used to create multiple appointment instances. Possible attributes concern who wants to make an appointment with whom, when, where and why. Additional tailored software needs to be developed or bought to integrate appointments with a calender application such as Google calender or Outlook in runtime. |
Control | This entity contains steering attributes, such as ProcessId, CaseId, TaskId. |
Relation between cases
When a case is related to another case, the related case "knows" with which case it is related, but not the other way around. The main case may use the result of the related cases, so related case contribute to the main case. Furthermore, the fact that the main case does not know its related cases is also due to the fact that such related cases may come into existence after the main case is long closed. So a complaint case will contain the Id of the related application case (as part of the complaint case entity Case data) but the application case will not contain all Id's of the complaints that are related to it. Lists can be used in Blueriq to navigate from a main case into its related cases.
See also
More information on how to design dynamic processes in Blueriq can be found here: Designing dynamic processes.
Everything about persistency management and aggregates can be found here: Persistency Management guide.
A visualization of most concepts discussed in this article can be found here: Blueriq visuals.
Specifically for dynamic case management and persistency management, see
Dynamic case management | Persistency management |