Wishlist for CiviCase

Published
2011-08-09 12:09
Written by

Given that there's an upcoming code sprint in the UK where rumor has it there will be some work done to improve CiviCase, I thought I would put my wishlist out there and get the community's response.  I'm a pretty frequent and detailed user of CiviCase, and although the majority of our actual service delivery is interactive, either on the phone or in person, we send and receive a lot of email correspondence, some of which ends up being relevant to one or more cases.  So one category of improvements I'd like to see involve the email processor and its functions.

 

I wish the email processor would:

  • allow me to select multiple activities at once to be filed on a case (perhaps with a checkbox interface similar to what appears in a contact search);
  • allow me to delete activities that have been attached automatically to a contact, sometimes by mistake;
  • allow me to see a reference in a user's activity stream after an activity has been filed on a case: something like "activity filed on case 25098";
  • allow me to configure an organization contact with an email domain, so that all emails from that domain are filed on that organization's contact, rather than on individual contact records. There are some organizations with which we have very loose associations, and we don't want to bother maintaining individual contacts - we just want to see all of the email from that organization in a single stream.

 

We also tend not to put client's names in emails that we send outside our walls, but instead refer to case numbers.   Currently, the only way to find a case or a contact by case number is through the full-text search.  It would be nice if there was a specific search box to search by case number.

 

After using CiviCase very intensely for three years or so, I'm wanting to see the CiviCase dashboard (different from the client dashboard) laid out differently.  I think it would be more helpful to see a single list of all my open cases (with the option to switch to everyone's open cases).  In that list, it would help me to see the date of the last activity, the date of the next activity (scheduled or proposed) maybe a couple of other columns, like the case type (a field which we use to describe the service package we're offering, rather than the problem presented by the client).

 

So there you have it, my top three suggestions - email processor improvements, case number search, and updated dashboard.   I'm curious to know what other intensive users of CiviCase think of these ideas.  Whatever folks think, I wish the team a productive and fun time at the upcoming code sprint!

Filed under

Comments

Cases aren't the only thing I'd like to be able to go-to by entering the number. Often I want to access a contact, contribution or event by id & the way to get there is pretty long winded.

This last issue of Contribution ID came up in training just the other day. If we send out Invoices with the Contribution or Membership ID on them then it would be most useful to then be able to find them easily - eg when the payment comes in - ideally have the ID show as part of the record - just as we do with the Internal ID

Well finding a contact by ID is pretty easy, just stick it in the url after /civicrm/contact/view?cid=

But I know what you mean. Search by ID is a pretty easy search for a computer, so it shouldn't be too hard to add that to search fields, I would think.

Andrew - Can you detail out the changes you'd like to see in the dashboard? Currently we have

My Cases With Upcoming Activities

and

My Cases With Recently Performed Activities

 

Sounds like you'd like to merge those two groups into one list? What would the sorting be? Which columns in  the current layout do you think are superfluous?

Yes, I think I would like to see it be one list, and to include only "open" cases, i.e. those with a status of "ongoing".  The columns are actually very good as they are, I think.  The STATUS column becomes superfluous if the selection criteria include status (because all cases in the list by definition have status=ongoing).

As far as sort order goes, I don't know what other people think, but I would personally support sorting on the most recent activitiy date, with earliest date at the top.  That has the effect of prioritizing open cases that haven't had any activity in a while.  When a case has some activity, it goes to the bottom of the list.

Others may not like this, because they have a different reason for using the dashboard.  I guess ideally it would allow for sorting on different fields to accommodate preferences, but that would be mine.

Although I thought I was going to find the "Summary of Case Involvement" table helpful, it turns out I almost never look at it.   When I want something like that, I run a report.  So, I would vote for removing it, or moving it to the bottom of the dashboard.

Maybe there could be three lists, each of them able to be toggled into "just my cases" or "everyone's cases".

1. Ongoing

2. Recently opened

3. Recently closed

 

Right now, the list shows "cases with recently performed activities" and "cases with upcoming activities".

If we could somehow find screen real-estate, it would be great if these could be in one list, with the "most recent" and "next scheduled" activities as columns.  The status field could be deleted from the layout, because it would be obvious from context.   I'm not sure how people are using the case roles, but it may also be workable to delete one of either "my role" or "case manager" from the grid to make room.  In our organization, those two columns almost always either display the same information, or have one blank column.

For delete activities as a workaround you can delete if you first search -> find activities. If I remember right it was decided that you can't edit inbound emails, consistent with the way you can't edit them in your email program, and I think the delete button (which is normally visible on the view activity page) was originally hidden to avoid inconsistencies in the audit trail with email activities that had been filed on case, but then around 3.2 the way the filing works changed, so I think it should be possible to make delete visible again.

Anonymous (not verified)
2011-08-10 - 00:46

I'd like to be able (without plugins and hooks) to have a case launched by completion of a front end user form (a profile would be fine) with that kicking off a case allocated to someone (and potentially the person it is allocated to depending on the values in one of the fields filled out so that e.g. if they pick "please send me a leaflet" they go to one person and if they pick "membership enquiries" they go to another.

 

Since I think that this can be acheived already using hooks and the API I suspect that making it do-able via the normal admin screens is not a huge job?

It would be great if a web-based administrator could run a search, pick out a list of contacts, and create new cases for all of them. The same affect can be accomplished using a script or module, but I suspect it would feel more empowering in the core web UI.

1) In case management relationships are used fairly heavily. Currently to create a relationship, you have to create the related contact first if they aren't in the system. This ends up taking many more clicks than if you could create the new contact on the fly the way you can with the overlay popup when creating a case. It would be neat if this same popup was on the relationship add screen.

 

2) Case dashboard gets slow to load when you choose all cases and you have a couple thousand activities in the system.

 

The issue of case dashboard slowing down when you have a lot of activities in the case system brings up a couple of thoughts.  I've long been a proponent of having all (or nearly all) updates to case-associated fields happen through activities.  To me, as a professional case manager, this makes sense because everything that might cause an update to a case record IS essentially an activity, and should be recorded as such.  But this has always been counterbalanced by the efficiency gained by storing some values on the case record itself.   I don't know if the case record stores the date of the most recent activity and the next scheduled activity, but it would seem reasonable and efficient to do so.

The whole idea of storing at least that much information on the case record whenever an activity is posted to a case seems like a good decision.  It might then provide the basis for extending what other things get updated to the case record when different kinds of activities are posted.  I'm not sure how much of this got implemented in previous versions of CiviCASE. 

It's a trade-off. Storing duplicated info in the case record will lead to a slew of future bug reports of the form "XXX doesn't match when YYY". It already happened a couple times with case status and end date (which are themselves items that can be determined from the case story, and so are duplicated info.)

I'm not sure at this point where the bottleneck is. If it's something like a code loop with secondary lookups like access checks then storing duplicate info would have no effect on speed.

 

I suspect the queries that we use for the dashboard are not optimized. Scaling to thousand - million activities should not be a big deal on a decent machine with mysql. If this is a big issue NOW, we should spend time and see what we can do to optimize those queries

 

lobo

This is a great post. CiviCase works perfectly if each case is always receiving the full attention of the administrator. But at least in our case, this is more the exception than the rule. The admins almost always want to perform many tiny actions (such as marking an activity as complete for a number of student at once). Here's my addition to the wishlist.

 

1. Select and change the status of the same activities on multiple cases (not just within a case) - e.g. these 5 people completed this activity

 

2. Make it possible to change activity status via inline editing - expand a case view, and tick an activity as completed - having to go to edit and click save on every little thing made CiviCase pretty much unusable for us as a way of managing admissions on university level courses

 

3. Make it possible for a change of status in an activity to trigger a change of status in another activity and/or in the case status (e.g. if I mark activity Application complete as completed, I'd like the case status to change to completed)

 

4. At the moment, if you change the case status, you have to mark that action as complete - because this change is in itself an activity - and this confuses our admins no end. Why not just assume that clicking OK makes it complete or at least set Complete as default.

 

5. Make activity timing relative to the completion of previous activities - not the start of the case (or give the option for each activity)

 

6. Provide an interface for editing case settings - we need to constantly tweak the cases in small ways and the XML files are too easy to make mistakes in

 

7. Make it possible to have the same activity in multiple cases

 

8. Provide reports that can report on activity status

 

Basically, I think we need a CiviCase Lite - something that can easily and quickly define contact workflows and can hide the complexity from admins.

 

Re 1: One possible approach would be: from Find Cases results, have a new task in the actions drop-down for Change Activity Status. This could take you to a form to enter activity type & new activity status. Is that what you have in mind? Would others find this useful?

Re 2: Perhaps a "Complete" link alongside Edit | Delete ? Should this bring up a confirmation dialog, in a similar way to "Disable" links?

Re 3 & 5: We've discussed at the code sprint allowing for more complex workflows. The consensus was that the variety of different workflows that different users might want to achieve is beyond what can feasibly be implemented in a short time with static configuration settings. However work has been done at the sprint to make more information available to hooks (see http://civicrm.org/blogs/dave-d/improvements-being-worked-uk-civicase-portion-code-sprint), which opens the way for custom modules to implement complex workflows without hacking core CiviCRM files.

Re 4: We aim to address this during the sprint.

Re 6: This is a frequent request but also a large change. It might be a good candidate for a Make It Happen - would you be interested in initiating this?

Re 7: Could you describe a use case for this?

Re 8: Could you give a little more detail on what you'd like to see?

Dave J

 

 

Re 1: Yes, this would be great. The problem is that activities have too many statuses. It would be great if each activity could have its own status lists - most of them only need two for on and off - but they end up being cluttered by one off edge cases.
 
Re 2: This would be perfect. I would prefer not to have a confirmation of this - just mark the change clearly visually. If you have to do more than 10 of these in a row, the confirmation dialog gets pretty tiresome. Speaking of which, the distinction between the activity subject and name is a very fine one and basically irrelevant to us. It would be nice if it could be filled out as the activity name by default.
 
Re 7: We have a number of course with identical activities: E.g. Check for academic acceptability but (if I remember correctly) during the set up, we had to choose different names for these for every case which makes things like creating reports extremely confusing because we always have to look up which of the wordings for activity names applies to a particular course case.
 
Re 8: Have a report in which the status of all activities is clearly visible at a glance. The problem is that for us, the status of the latest activity is the real status of the case we're interested in - the case status is only the last thing we want changed.

Re 7: I think this is an issue specific to your site [I've done development work for techczech]. You're referring I think to having the same activity type in multiple cases and this is certainly possible. The issue is that you have customisations to assign specific activity types to specific users automatically upon creation and there was a requirement to assign e.g. academic checking to different users depending on course type. IIRC this had to be done based on activity type alone because the case type wasn't available in the hook. If that's so, one of the changes made at the dev camp may help. We can discuss this further privately, it's not a generic CiviCase issue.