I’m just writing this to get it out of my head…

So, a couple of days ago Kit said:


I’m really looking forward to reading that but in the meantime I seem to be spending far too much time (i.e. any) thinking about what a case management system actually does and what a meta-case-management system, or platform if you like, would actually look like.

A case management system is basically just a state machine combined with an identity check, authorisation, data fetching, data views and the ability to trigger external events. A state machine is made up of states and actions – some of which change the current state. Finally, a case is made up of data related to that item and its current state.

So, let’s imagine a meta-case-management system. It would be made up of lists of:

  • Data fetching functions (e.g. from various DBs or APIs)
  • Data views (e.g. showing all, limited or partially obfuscated data about the case or cases) – can also include data input views to add information to the case data store
  • Events (trigger an API to perform an action such as sending an email using a specific template plus the data held in the case or storing some / all of the data in the case in a DB)
  • States
  • Actions
  • Case worker roles (for authorisation)

Assuming the part of the system that allows a back-office worker to log in also assigns them one or more roles the next step is wiring things up in a pseudo If This Then That manner.

Some examples:

  • If <state> and <role> show <data view>
  • If <state> and <role> show <list of a subset of actions>
  • If <state> and <action> do <event> and do <data fetch> and set state to <state>
  • If <state> and <action> do <data fetch> and show <data view>

Note that <state> + <action> entries don’t need to include <role> as the case worker won’t be given the option to select an action if they’re not allowed to do that thing when the case is in that state.

Some combinations could include meta things like:

  • If <state> and <role> do <data fetch (of all cases assigned to this case worker)> and show <data view (of list of cases with built in sorting and filtering)>
  • If <state> and <action> do <event (add a new case worker using data from current view)> and show <data view (list of all case workers)> and set state to <state>
  • If <state> and <action> do <event (trigger <another event> using each case selected in the current data view>

The last one gets a bit complicated if some actions can be done to some cases but not others but even that can be solved by triggering a rule every time a case in the list is selected / deselected and updating the list of actions accordingly.

It might get a bit fiddly around dealing with one / many cases but that could also easily be solved by having a case worker specific variable holding the unique ID of the case currently being worked on (or not for when working on lists of cases).

Data fetching and events probably need to be individually coded but once done there is the potential for reuse (e.g. different templates for email or SMS).

The data views could potentially be defined by using a UI.

I’ve avoided writing about one potential spanner in the works which would be the need to add an extra list:

  • Conditions (takes case data and role and returns a boolean value)

This might be needed to handle some particularly tricky corner cases but I think the vast majority of case work systems could be defined using the simple rules above.