Case Improvement Ideas

Published
2010-07-29 12:23
Written by

I've been working through case configuration with a few clients over the last several months and have run into a few areas where I think the functionality could be improved. The core team asked that I outline it for the community to see if other groups experience similar workflows and would benefit from these changes.

The issue mostly revolves around case roles and case resources. Following the conventions outlined in the online documentation, I generally present case roles as individuals *directly* involved in case resolution. Most of the time this will be staff who have access to CiviCRM and will be actively tracking and adding information to the case record. In contrast, case resources are people (or perhaps organizations) that are *indirectly* involved in case resolution. For example, they may be outside agencies, local government, or other organizations who are contacted and brought into the circle to assist with the issues. They do not have access to CiviCRM, so the primary purpose of attaching them to a case is to serve as a contact and reference directory.

With these definitions and usage in mind, here are my thoughts:

  • I'd like to be able to limit the contacts available to case roles to a group, similar to what we can do to case resources via the settings.xml file. Since the case roles are people directly involved (staff) and likely very limited in number, it can be cumbersome to use the quick search field to cycle through the entire database of contacts. Currently this can be done with hooks, but I suspect it would be a commonly used feature, so it would be great to make it part of the case configuration. And ideally both the case roles and case resources group selection could happen through the interface, rather than in settings.xml.
  • On a similar and related note, I think the activity assignees contact search should also be easily limitable to a group, as that too will likely only be used for internal staff.
  • Currently, case resources are a group of contacts that simply are added to each case record as a list -- a directory of contacts visible in the case record for convenience. The problem with that is it will either not be useful, or quickly become cumbersome, unless all your cases are very homogenous in type and scope. In other words -- if you are always only working with 10 or so contacts outside of your organization, then providing a quick list of those contacts could be useful. But if your case management is more diverse, you either will not have the right contacts available in that short list, or you will begin to grow the number of contacts in the case resources group to the extent that it is no longer very useful. Thinking through this, I have two ideas:
  • A default case resources group could be defined for the entire system, but a case type-specific group could be defined with the case type xml file. This type-specific resources group would supersede the default group. So let's say that 8 of my 10 case types are very similar in nature, and I define a single case resources group to store the dozen contacts I want available. Great. But my other two have very different "resources" that are tapped, so I define different resource groups to assign to those two types. Functionally, the existing behavior of case resources is preserved -- we simply have the option of defining a type-specific group.
  • A second option is to make resources work more like roles: I define a single group in which I put my resource contacts, but within a case record I only add to the case those contacts that are relevant to that specific case. So let's say my case resources group has 50 contacts within local government in my county. When I open a new case, I decide to add three of those contacts to the case as a resource -- those three contacts all are health and human service related, because the case I'm working with deals with that subject and I want easy access to those people and numbers. I don't really care about the DPW director, who is in my resources group but irrelevant to this case. This second option alters the structure of resources and does require more management work (you need to add the contacts to the case), but it provides much more control of who is truly considered a resource to a specific case.
  • I'm wondering how people feel about the relationships being listed within the case record. Personally, I feel like it clutters things. Especially because the case component can easily generate a lot of new relationships as a result of the roles.
  • On a related note, for staff involved in case management, they will quickly have a huge explosion of new relationships because of the case roles. This includes the possibility they will have multiple relationship records of the same type with the same individual -- if that individual has multiple cases which they are involved in. I think the relationships mechanism is appropriate for this purpose, I just think we need to determine a better way to handle the potential influx of records. And with regard to the multiple relationships with one contact, I'd like to see some way to identify the specific case within the relationships table.
  • I'm curious to see how others feel about these issues -- especially with regard to the case resources ideas.

Filed under

Comments