Dansk
Many standard systems offer just one entry point and one site for all user types. Casewhere can create as many unique sites as are needed to secure separate entry points, separate URLs, and separate user experiences for every single user type of your solution.
When envisioning your solution, the experience that you want your end users (a.k.a. citizens) to have will differ markedly from the features that you want to offer your Caseworkers. Citizens need ease-of-use, intuitive flows and easy access to detailed information. Caseworkers, on the other hand, typically require short-cuts, autofilling, advanced filtration, and compact information views, as their focus will be on speedy execution of work.
At the same time, you want to avoid that the flow of data between Caseworkers and Citizens become cumbersome, inconsistent and complex, which often happens when you try to reach two quite different goals within one system.
Casewhere offers a solution to this, as the workflows and processes can be configured at a separate abstraction level from the user interfaces. What this means is that you can specify the data objects, flow of data, validations, authorisation logics, events and triggers, and business rules across all user types without later being restricted in the specific user experience that each user type will be given.
Typically, public service-cases require multiple steps to be carried out and information to flow back and forth between stakeholders multiple times before a case is concluded. While the data flowing back and forth must be consistent at all times, how this data and what parts the information will be presented must usually be controlled rigorously.
When building up a Casewhere solution, you will build up layers of logic ensuring both consistency, separation, and customization.
At the lowest level, you will define the exact data model needed to store all relevant information.
At the next level, you will define the exact authorisation rules for this data, i.e. exactly what data can be accessed by what user types.
At the third level, you will define the flows that each different user type can take, while manipulating the data that her os he has rights to. An example could be, that a Citizen is allowed to create a support case with a certain set of data, but is not allowed to then add actions to that case beyond the state “awaiting allocation of Caseworker”.
At the fourth level, we start to add triggers and events to the flows. E.g. that information is sent by email to stakeholders, that data i validated via external interfaces, that payment is done, and so much more.
When we have the above logic in place, we can add as many completely different sites “on top”, as we need. E.g. we can have sites for Caseworkers, Citizens, External Stakeholders, Administrative Staff, Analytics, etc. The experience for each site can be completely different, but they will all tie up to the same underlying logic.
This separation of responsibility within the system ensures both consistency and separation of data and user experience. It makes sure that even with a standardized system, like Casewhere, you do not need to compromise on customizing the user experience to fit to each of your stakeholders, while at the same time adhering to the strictest of data security requirements.