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:
- Drupal Rules provides a UI so that site-admins can define their own workflow. CiviCase (before and after this proposal) uses XML as the main definition of the workflow.
- Drupal Rules defines a full ECA (event-condition-action) system for defining workflow (with all its power/complexity). This proposal provides two narrower features: (1) another hook that can be used to define workflows and (2) a specific workflow ("pipeline") based on executing all tasks in sequence.
great idea, and could be very useful. a couple other use cases for cases that I've come across:
- membership applications... such as a professional society where there are certain documents/certifications that must be verified, etc. before a member is accepted into the org. in such a situation, there may be multiple steps taken by the membership coordinator to accept the application, coordinate with the applicant, and verify or reject the membership
- grant applications... while civigrant may be useful for basic grant application management, I've had orgs use civicase to setup more involved workflows for accepting grant requests and processing them through the org.
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:
- Conditionals (eg a <condition> tag which accepts a conditional expression in PHP, Smarty, or something similar)
- Forks/Merges (parallel lines of activities -- perhaps modeled by spawning ActivitySets)
- Per-activity events (eg <onCreate>, <onComplete>)
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?