CiviCase is a case-management system for tracking multistep interactions with constituents -- such as social support services, constituent services, and applications for employment. The CiviCase toolset enables organizations to provide a more consistent quality-of-service to their constituents by setting out a base timeline for the services to provide to each constituent. This is a powerful tool that can be adapted to a variety of organizations and requirements. Unfortunately, the initial configuration process for CiviCase currently requires some technical skill -- the site administrator must prepare an XML file, copy the file to server, test, and repeat until the XML file is just right. Thanks to the support of the National Democratic Institute, that's going to change -- we're going to make it easier for site administrators to setup CiviCase without requiring deep technical skills.
The project's goal is to expand the CiviCase configuration GUI to allow complete definition of a CiviCase "case type" (including the options that are currently available through XML). Rather than talk through this, I'll let the pictures do the talking:
Comments
Hey Tim,
That sounds really cool! I see you are starting from UI perspective but it is probably good to do also some under-the-hood changes e.g. when reassigning a case storing the a link to the old case.
Also with the UI I got some wished and don't feel you have to implement them. But probably we could give a case the same kind of screens as the contact details has. So with multiple tabs, custom fields, a hook for inserting extra tabs etc... The reason I am asking is because I am working on a document solution for CiviCRM and those documents could be stored at contact level but also at case level. But at the case level I have to do some jQuery to get the document tab in the right spot and that didn't make sense. Also a case is usually something which groups a lot of information and the manage case screen doesn't really make an overview.
Anyway I love your idea!
I think you're right that the "Manage Case" could be improved. If you're going to pursue it further, it might be good to publish a mockup.
Fortunately, I think there's a lot of room to implement/improve the "Edit Case Type" and "Manage Case" screens without coupling the efforts.
Sounds really good Tim! As you might know we have a couple of customers that use CiviCase extensively, so if you want to bounce ideas of any 'real' data or processes please let us know! We will happily provide some real life examples.
This sounds fantatsic! It also looks like a typical administrator could manage the configurations without to much help. Is this going to be part of CiviCRM core or an extension? Also I currently manage the CiviCase XML files in a version control system and push out standard configurations ( ie such as standard activity types and standard timelines that are the same for many organizations) to many CiviCRM installations. How would this be impacted by this enhancement?
It's going to be part of core (CiviCRM 4.5).
The goal is to support a developer workflow like Drupal's Views or Features, eg:
Notably, this involves a change to how the XML is loaded. At runtime, CiviCase will locate the XML by checking a few places:
We're really looking forward to working together on this, Tim. I'm sure it will help many new organizations take advantage of the powerful tools CiviCase provides for connecting constituents to their governments.
I think it will be very important to think through and clearly articulate the difference between the file-based config and the DB-based config. It sounds like it could easily be confusing -- a developer may make changes to the file-based xml file and not realize that because it's been modified through the UI, the DB version is what is currently being used for the given type. Perhaps saving the case via the UI could simply write to the xml file, rather than have a separate export step.
Also --
Remember to keep in mind the Settings.xml file, which contains some general config settings for cases. They could likely be added to the existing settings framework, with the exception of the noneditable activity types (or at least they would need some adjustments to work within that existing framework).
With regard to the activity timeline "advanced" panel -- I'd suggest making those fields static at the top of the activity list, rather than in a hidden panel. They're not really that "advanced" and should probably get more visual presence.
This will help and increase a lot the usage of CiviCase, what I think will be very nice to the increment of Civi at all.