Opublikowane
2010-07-29 12:23
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
I think filtering the selection of contacts for Case Roles (and possibly Assignees) by group makes a lot of sense. I also like the idea of allowing case-type-specific case resources groups.
I'm not sure what you mean by this question:
I "think" you're referring to the fact the "Case Roles" are also listed under the "Relationships" tab for both the Client and the person in that case role. Is that it?
Looking forward to comments by other folks using / evaluating CiviCase.
In the "Other Relationships" panel, there's a listing of "client relationships" -- which is just a list of whatever standard relationships exist for the contact.
Not a big deal. I think they're just there for convenience, so you don't need to exit the case in order to see what relationships the contact has. But it can start to clutter the interface a bit. Maybe clutter isn't the word -- when I'm in a case, I expect to just have info relevant to the case. Not additional relationships that may or may not be relevant to this specific case.
As for the filtering, could be easily done by overriding the template form, with the question:
is this already possible to override a case by type as for events ? eg. CRM/case/form/42/edit.tpl only applies to case type 42 ?
(that would easily as well allow to deside to display or not the relationships and so on)
X+
no, to my knowledge you can't have case-type-specific overrides, as with events and contrib pages. but even if you could, my personal feeling is that some of these options would be useful enough it would be better to include in the interface so they are fully accessible to non-tech/programmer users.
But that's probably a much simpler improvement to test if /civicrm/case/form/{case type}/edit.tpl exists before using civicrm/case/form/edit.tpl than adding a potentially long list of customisation (limit the contacts for role x to group y/display list of relationship/...), modifying the templates+php, adding all the unit tests...
(at least for profile, that's a onliner)
Beside, configuring a case type is already out of reach of the non-tech/programmers and I'd argue that those able to create the required xml file would be ok to create some custom templates if so they need.
Moreover, it'd allow to customise as much as you want, eg. instead of limiting the contacts in the autocomplete on a group, you might limit them on a subtype/tag, or whatever you dream of. You might as well limit it on values of custom fields (eg. if the case as "NY" as value for the custom field state, limit the contacts to those on this state).
My fear is that your list of "most common modifications" aren't the same as mine, nor that someone else, but that being able to write custom template per type is much easier and almost as powerful as going the hook road (and should be fairly quick to code)
X+
you're right that case configuration is already beyond the basic interface, so there's an argument for not worrying about adding these options to the interface. if they were in the interface, I would see them as basic dropdowns included in the case types management (which is available through the admin menu). I like the use of groups because they are flexible enough to suit just about any need. Your example of a subtype/tag could be reproduced with a smart group.
My original thinking was just to add it as an option to the settings.xml file and to the individual case config files. The settings.xml already has an option for the case resources group restriction, so it would make sense to just extend that with additional options, or to create additional meta options in the case xml files.
I do think there's a leap between configuring the xml files and modifying templates or hooks. I have users who have created their own case xml files but who would never have touched code.
but beside potentially having tons of them, you still cant have groups that filter the contacts based on the values in the specific case (or of the main contact of the case, but that's a one liner in the template.
X+
I think I agree with most of this except one thing I'm missing and is preventing me from commenting on the suggested solutions is what task is being performed at the time the problem is occurring. For example I get that having 100 relationships listed in the Other Relationships can be visually cluttering, but what task is it making difficult? Ditto on a contact's relationship tab.
I would find it really useful to be able to limit the number of cases of type X for any given client -- so that an individual can only have one Housing Support case open for them at a time.