When the case has reached its goal, it's archived. Reaching the goal could for example be that the resulting product is stored in the back office, or the change has been altered in a register application. It is time to archive the now completed case.

There are different types of data that could be useful for later. Most of the time the data could be classified in the following categories:

1. Case Trigger data, what triggered the case? What did the applicant request in the first place?
2. Case Resulting data, what is the result of the case? A decision? A product? 
3. Case process data, what happened in the case? How did the the trigger lead to the result? What steps have been taken?

The different categories might need to be handled differently when the case is completed.

What data is needed is most likely a question that can only be answered when the whole business context is available. What data is needed on the long run, versus what data is needed within the case to make decisions.

Trigger data

When the trigger data is considered for example, we need to know what possible other actions might need this data later. Who is responsible for the trigger data? It might be another system that handles the data, and only after that, a Blueriq case-type is started. Then the other system is responsible for maintaining the data. When the user applies the data in a Blueriq system, it might be necessary to keep this data in some form of administration. Often it is needed for other cases to know how many applications the user has already done in the past period, questions like that could be handled by the administration. From this perspective, The Blueriq Case-Type is merely using the administered data, but not maintaining the data itself.

The trigger could also be some form of mutation on an object that is not maintained in a Blueriq application. For example changing the parameters of a mortgage could be a trigger for a new Case in Blueriq. The mortgage itself is still available in the back office system. Blueriq uses this data to facilitate the change, where the result is presented to the back office again. Only when this change is processed successfully, the goal of the case-type has been reached. This while the Blueriq system is never owner of the Mortgage data itself. Even another Case-Type could facilitate a different change in parallel on the same mortgage. The back office should keep all cases that depend on the mortgage up to date when changes are processed, so within the case-type we can determine what to do with the change.

Resulting data

The resulting data is where the import decisions are stored when the goal is reached. This might in many situations be some form of administration with a global structure. This administration can be used to store the main decisions like "did we decide the applicant could have this product?" "What is the amount of the subsidy we decided on?", "what are the parameters of the contract that was concluded?". Note that in many cases the result would just be the actual product stored in the back office. The system that maintains the results should be able to answer questions like, how much money did the applicant receive over the past year, or did he pay over the last year? Questions users might need to decide on different cases in the future. Also new cases might be started based on the resulting product (for example new changes or corrections).

Case process data

All data which has been maintained in order to get to the result is the Case Process Data. This type of data is most specific for a case-type, and can hold all kinds of supporting decisions, data on which the decisions are made, procedural data (when did I request extra information, when is this information supplied). This data is very important for explaining how the decision has been made. It it typical data which should be stored in your archive for reviewing it much later. Therefore you don't want to depend on any operational system when this is not strictly necessary. It might be best to store this in a document in your DMS, where you can guarantee it cannot be changed anymore, and will remain even when the operational system is changed or even replaced.

Other ways of storing this information would be an export of all data from the case, for example in XML format. This would make the storage available for the more technical users, to backtrace the Case process later.

Operational case-data that is deleted when the case is completed:

• case-document (contains relations to other operational data)
• case-metadata (labels added to active cases for searching and creating lists)
• case-dossier (all operational data where all decisions are based upon)
• case-process (all open tasks and reached milestones, timers, possible incoming message events)

Relevant data might also be stored in logfiles or in Blueriq data tables. Examples could be

• audit log table in the SQL database
• trace/timeline tables in the SQL database
• application logfiles
• comments tables in the SQL database

Blueriq will not touch this information or delete it by default. At every solution you should determine what to do with this information after a case has been completed.

What does Blueriq offer?

There are different ways of storing information from a Blueriq application. All of thos come with their own pros and cons. At the moment Blueriq does not contain a plug-and-play out of the box archiving function that serves all needs (if this is even possible). 

The DCM-Foundation models have implemented an example of all the possible solutions described above. Which (of course) could be altered to fit your specific needs.

Are we there yet?

Not one solution satisfies the requirements for a proper storage of all different data usages. Most likely the cons outweigh the pros of each possible solution. Therefore other solutions are being used at our current customers. 

Trigger data and Resulting data is often stored in the back office used by the customer. When this is not present, Administrations containing this data can be created by using Blueriq combined with a service to store structured data in the database. For example, the Object Relation Mapper (ORM) could be used to store data in an SQL database, for later use. A different Blueriq project can be modelled to maintain this data, construct service operations for specific questions needed in other applications. Note that the administration should also be build to cope with data lifecycle management. Together with the customer must be determined what data is relevant for later use (in a structured way) and what data can be archived as "case process data". Form the perspective of the Case-Type, this will be external systems with their own management, where the case pushes data to.

Case Process Data is often either stored in an aggregate form, or also stored in a structured database. When stored in an aggregate form, the data can easily be loaded to start a new case on. This method is not recommended, since the data has to be maintained in this aggregate form, together with the corresponding model, for a long time. The data is also not searchable without a Blueriq model, but this might be more of a problem for the other data types. The Business Engineer should be very conscious on the source of the data, some data might only be stored in aggregate form, while other data, like the result is stored in a different component, and should therefore never be kept in the aggregate as source for later decision making. Keeping the data in a document would be a safer way, but then new cases can only depend on the data of the previous trigger data, resulting data, or the product stored in the back office (which might make sense).

On the future roadmap we will investigate what is still needed for proper archiving and the gaps at the customers using the Blueriq Platform.