CiviCase is generally described as "a container for activities". As a container, it's well-suited to two scenarios:
- The activities in the case are identified and scheduled on an adhoc basis -- there's always a person (a case manager) making the decision about when to schedule the activities.
- The activities are performed according to a fixed timeline based on a reference date -- e.g. the first meeting is scheduled 3 days after the case opens; the next meeting is 14 days after; etc.
However, a container of activities can be useful in other scenarios -- for example, consider the case of hiring a volunteer to work in the children's art program:
- The director of the children's art program needs to meet with the volunteer to determine whether she has the proper skills and experience in art.
- The HR manager needs to obtain consent and details from the volunteer for running a background check.
- The HR manager needs to commission the background check -- and followup on the results.
- The office administrator needs to print out an ID badge for the new volunteer.
- (And there may be many other steps before, between, and after these steps.)
In a mid-sized organization, the list of steps can be long, structured, and nearly identical for each volunteer. We could use CiviCase with its timeline feature to schedule all of these steps. To get the full benefit of a timeline, we would need to set a date for each of the activities as soon as the hiring process begins. However, suppose we schedule a task for the office administrator to prepare a badge after 7 days. If the background check comes through quickly (within a day), then the office administrator will needlessly wait. If the background check takes two weeks, then he'll print out the badge too soon.
It can be challenging to deploy a software solution which organizes all these steps electronically. I'm not going to propose a technology to solve all these challenges for all organizations -- that's a tall order! But I do propose adding a few tools to the CiviCase tool-belt:
- Create a new extension, org.civicrm.caseutil.
- Add support for "Case Listeners" which use a "Case Analyzer" to decide on next step.
- Add an example "Case Listener" for simple, sequential workflows -- aka pipelines.
For a more detailed specification, please see http://wiki.civicrm.org/confluence/display/CRM/CiviCase+Util (UPDATE: http://wiki.civicrm.org/confluence/display/CRM/CiviCase+Util).
Comments
So if I understand you this is like a mini version of Drupal Rules.
Yes and no. Like Drupal Rules, it's generally relevant to the topic of workflow and coordinate activities. However, there are two key differences:
great idea, and could be very useful. a couple other use cases for cases that I've come across:
in any case -- it's not unusual for a case workflow to have branching steps -- IF the application is accepted, do steps A, B, C ELSE if it is rejected, do X, Y, Z. so having a more direct way of interjecting conditional elements into the pipeline would be great.
Agree that conditionals are important though they obviously add more complexity. A few logical additions/expansions to the pipeline would be:
I wasn't initially thinking to include that functionality in the pipeline implementation, but I don't think it would be too hard for an experienced developer to take a stab at that (esp. if we have some good unit-test idioms).
The appealing things to me are that (a) we can experiment with these features outside core and (b) we have the fallback option of writing listeners in pure-PHP.
I like it, just for me two-way sync between people's calendar and activities is a more useful workflow helper. It's separate, but it's related because to-date it's blocked any suggestions for a non-trivial workflow with CiviCase, but it also hasn't been a high priority to solve it. People just end up accepting/creating meeting invites in their personal calendar. It's because many of the activities actually have a scheduling back-and-forth conversation before the date gets set. Given that calendar functions already allow for that, and have integration with email, people use calendars and email to handle this workflow. Then they use the email processor at the end to file the results.
So that doesn't mean the feature won't be useful for others - it's entirely possible I'm alone on these observations - I'm just not sure where I'd use it.
What do you think have been the major obstacles to defining that two-sync? The existence/funding of the right project? The integration limits of popular calendar tools?
Priorities mostly. Calendar and email function to support the workflow, and Civi functions as a place to store the *results* of those workflow activities (or e.g. summaries of relevant parts) and as a reporting source. Moving beyond that might be desired but just not a high enough priority for funding/time.
Only just seen this, but I think we'd be keen on it, too. We have several scenarios where the data that activities actually happen is significantly different from the predicted date in the XML for the case type. In those situations, when an appointment gets moved, for instance, the activities which need to happen at certain points after that appointment don't get moved with it. Having the kind of listener functionality you suggest would be a flexible solution.
But... I get a 404 when following the link to the wiki. What happened?
The document from http://wiki.civicrm.org/confluence/display/CRM/CiviCase+Util to http://wiki.civicrm.org/confluence/display/HR/CiviCase+Util .