How to handle long-term monitoring and archiving

Blueriq is a case-management system, and when the goal of the case is reached the case closes. The goal of the case could be anything, and typical examples are the approval of a mortgage, the granting of a subsidy or a successful registration. A requirement may be that after a long period of time has passed, a new case needs to be started. As use case in this article we choose the renewal of a registration. After successfully registering, the client has to update its entry every 5 years. The question now may arise how a new case for the registration comes into existence after such a long time.
 

Step-by-step guide

First of all, Blueriq is out-of-the-box less suited to create a System of Record (SoR, see Gartner's Pace-Layered Application Layers). This means that it is common to store the successful registration outside Blueriq in a SoR. This could be a relational database or any other system which focuses on the long-term storage of records. When the case closes, the corresponding records for running the case are deleted from the internal storage to free up space for new cases which are currently running. The ownership of the records of the closed case lies with the SoR.

The trigger that starts a new case for renewal of registration after 5 years should be created by the SoR and not by the product Blueriq. As the SoR is the owner of the records, the responsibility lies there to monitor these kind of events. Usually those are also not time critical, and the case may be started a day early or late. This can be done by a process that periodically checks all stored registrations if a trigger is needed. Once a registration is up for renewal, an event is send to the process engine and a new case is started.

If Blueriq would handle this long-term monitoring, the amount of running cases would increase linearly, as cases are never closed after the registration due to the 5 year timer. Only when a registration is discontinued can a case be deleted. This amount of open cases is a heavy burden for the process engine, and the performance will decline. It is therefore advisable to only have running cases if there are actions expected in the near future.