Some organisation / individual / relationship based feature requests for UK LIOs

[Michael McAndrew]

Hi there,

I work with a few non-profit organisations in the UK that are called "local infrastructure organisations" or LIOs - they are umbrella organisations that deliver services and support to other non profit organisations in a specific locality.

LIOs deal with organisations and the people that work for these organisations.  For LIOs the role that the individual plays at the organisation is key, and this puts a certain emphasis on the way that the LIO wants to view and use their data.  Here’s a couple of examples of the kind of work they do.

* They put on training events for staff of local non-profits, for instance, Mary Collins from Age Concern attends a training event on "Effective fundraising".  The LIO wants to ask questions like, what sort of organisations are attending fundraising events, or "what organisations working with older people have not sent someone to a fundraising event this year". 
* They help organisations work effectively by ensuring they have the right policies in place.  The LIO organises a series of "organisational health checks" (think case management!)  that consists of a series of standard tasks, for instance helped Green Lanes Youth club put in place a volunteering policy.  The LIO can then report on how many organisations they have helped put in place organisational policies this year.

I've done a bit of work on applying CiviCRM to the way these organisations work and come up with a list of things that (I think I'm right in saying) CiviCRM can't do and my thoughts on how to mould Civi to cater better for these needs.  Some of them are probably sensible requests – others might be poorly thought out.  I hope they are useful and would be very grateful for any suggestions on how to implement this functionality, or ways to do this with already existing functionality.  To start, I’ll concentrate on functionality that relates to individuals and organisations.

1) Be able to set individuals to use their employer address by default.  I imagine this would be implemented in a similar way to "use household address".

2) Organisation’s activity tab also shows activities delivered to staff of the organisation.  (I've already modified the relevant activity search to make this possible by adding an extra variable to the function call which is an array of the relationships you would like to retreive).  You could also use this, for example, to set a household activity tab to show events that members of that household attended.

3) Be able to control the visibility of profile fields dependent on the value of another field.  E.g. “hide phone number from public directory if age is less that 18”.

4) Assign an employee of an organisation to be the "main point of contact” for that organisation and use this person’s name in all correspondence (mailing labels) etc. addressed to the organisation, and in an online organisation directory

5) (perhaps slightly related to the above) a new custom data type of “contact” that you can filter by type of contact and/or relationship.  e.g. "a field on an organisation page called “First Aid Representative” that allows you to select from a drop down of all staff at the organisation.  (How this relates to relationships will need some thinking through

I have some more feature requests for events, case management and deleting, but will leave those for another post!

PS.  This post fits in with some pages that some people in the UK been creating on the wiki http://wiki.civicrm.org/confluence/display/CRM/CiviCRM+for+Local+Infrastructure+Organisations+(LIOs)+in+the+UK

[Michael McAndrew]

Hi again,

I've spent some more time thinking about roles (by which I mean role/position within an organisation - sorry for the confusing terminology) and points 4 and 5 in my previous post.

Roles

I thought peterd's ideas about positions http://wiki.civicrm.org/confluence/display/CRM/New+contact+type+for+Position+or+Office were very interesting and relevant.  I also come up against the problem of individuals on the database having multiple roles in life and different contact details associated with these roles.  It is often useful - and sometimes critical - that a mailing is not sent to a contact using their contact details for a certain role, e.g. don't send a whistle-blower an email to his work address.

I had been thinking of roles as an extension to relationships.  If someone is recorded as the employee of an organisation, the relationship record seems like the right place to record extra information about this relationship: job title, contact details specific to the role, etc.  It might be a really good idea (as peter suggests) to associate a contact with this relationship to allow you to record all associated contact information.  I guess the problem you would encounter here is that the model seems to be getting very complex, and that contact specific data could be recorded in three different places: individuals, organisations and positions/roles.

4 and 5

Below are three enhancements that would make it feasible (and really fantastic) to implement 4) and 5) as a type of relationship:

a) ability to specify that certain relationships are one-to-one, one-to-many or many-to-one (as opposed to implicity many-to-many as they are now).  This is necessary because implicit in the concept of a default contact is the idea that there can only be one per organisation.  In practice this would mean that if you have one person A as the default contact for organisation X and you try and assign person B to this role, CiviCRM says, Person A is already assigned as the default contact for organisation X.  You can only have one person assigned as the default contact.  Would you like to [Keep A] or [Update to B].

b) ability to specify that you want corrsepondence (in an email/mailing) sent to a relationship to the organisation if this relationship exists, and if it doesn't just to the organisation.

c) more emphasis on relationships when viewing contacts.  Ability to see relationships on the summary page - not just as a tab. 

OK then, I'm slightly concerned that this sounds like the ravings of a madman!  I hope you can make some sense of it, and that it is not too much to digest and answer.  Would be great to know what you think about this, and to hear any suggestions for implementing these features, and any alternative approaches.

Michael

[petednz]

Michael

Good to have the idea of a new Contact Type for 'Officers/Roles' being raised again. I had hoped it would get some pick up in the development of civiCase but haven't been able to monitor those developments at all.

Secondly, I have just run in to exactly this need too

a) ability to specify that certain relationships are one-to-one, one-to-many or many-to-one (as opposed to implicity many-to-many as they are now).  This is necessary because implicit in the concept of a default contact is the idea that there can only be one per organisation.  In practice this would mean that if you have one person A as the default contact for organisation X and you try and assign person B to this role, CiviCRM says, Person A is already assigned as the default contact for organisation X.  You can only have one person assigned as the default contact.  Would you like to [Keep A] or [Update to B].

b) ability to specify that you want corrsepondence (in an email/mailing) sent to a relationship to the organisation if this relationship exists, and if it doesn't just to the organisation.

I think you articulated it really clearly - madman or not.

[Dave Greenberg]

Michael - Lots of food for thought here :-) We went through both posts and divided them up into several categories ranging from "things you can do today with some custom coding", to things we'd like to either add to core OR facilitate by allowing more programmatic configurability (e.g. hooks), and finally things that need explicit sponsorship to get on the roadmap. I've divided up the list below, with some comments...

Can do today with custom template / coding

3) Be able to control the visibility of profile fields dependent on the value of another field.  E.g. “hide phone number from public directory if age is less that 18”.

Incorporating this type of logic into profile screens seems like a "custom coding" task - given the infinite number of conditions / results folks might want. We think this is reasonably do-able w/ either the jQuery or dojo Ajax library calling into an API from the page to retrieve "the age" (in this case) and setting properties. These "customizations" could become part of a library of add-ons for LIOs and similar organizations.

Facilitate customization

2) Organisation’s activity tab also shows activities delivered to staff of the organisation.  (I've already modified the relevant activity search to make this possible by adding an extra variable to the function call which is an array of the relationships you would like to retreive).  You could also use this, for example, to set a household activity tab to show events that members of that household attended.

We're thinking that a good solution here is to enhance the existing "tab hook" so that you can remove unwanted tabs. This would allow you to replace the default Activities tab with one that uses your modified parameters / function call. The hook could do this only for Organization type contacts. Since this is a fairly simple change, we've filed this for 2.2 : http://issues.civicrm.org/jira/browse/CRM-3845. You should also chat with Lobo about whether your modification to the function call is general enough to be incorporated into the core codebase.

c) more emphasis on relationships when viewing contacts.  Ability to see relationships on the summary page - not just as a tab. 

This should probably be addressed by providing a general mechanism for customizing the contact summary page - similar to what we've done for the CiviCRM Home page (dashboard). I've added a bullet point for this to the 2.3 roadmap: http://wiki.civicrm.org/confluence/display/CRM/CiviCRM+v2.3


On the roadmap

1) Be able to set individuals to use their employer address by default.  I imagine this would be implemented in a similar way to "use household address".

Scheduled for 2.3 - http://issues.civicrm.org/jira/browse/CRM-3338

Good additions to core for future releases

a) ability to specify that certain relationships are one-to-one, one-to-many or many-to-one (as opposed to implicity many-to-many as they are now).  This is necessary because implicit in the concept of a default contact is the idea that there can only be one per organisation.  In practice this would mean that if you have one person A as the default contact for organisation X and you try and assign person B to this role, CiviCRM says, Person A is already assigned as the default contact for organisation X.  You can only have one person assigned as the default contact.  Would you like to [Keep A] or [Update to B].

This seems generally useful. I've added a bullet point for this to the 2.3 roadmap.

5) (perhaps slightly related to the above) a new custom data type of “contact” that you can filter by type of contact and/or relationship.  e.g. "a field on an organisation page called “First Aid Representative” that allows you to select from a drop down of all staff at the organisation.  (How this relates to relationships will need some thinking through)

This seems generally useful as well - basically a "contact reference" data type. Will need some thinking about filtering options - since you would generally want to limit which contacts are available for selection. Filtering by group might be a good flexible approach ??

Needs spec and sponsorship

Roles
I thought peterd's ideas about positions http://wiki.civicrm.org/confluence/display/CRM/New+contact+type+for+Position+or+Office were very interesting and relevant.  I also come up against the problem of individuals on the database having multiple roles in life and different contact details associated with these roles.  It is often useful - and sometimes critical - that a mailing is not sent to a contact using their contact details for a certain role, e.g. don't send a whistle-blower an email to his work address.

I had been thinking of roles as an extension to relationships.  If someone is recorded as the employee of an organisation, the relationship record seems like the right place to record extra information about this relationship: job title, contact details specific to the role, etc.  It might be a really good idea (as peter suggests) to associate a contact with this relationship to allow you to record all associated contact information.  I guess the problem you would encounter here is that the model seems to be getting very complex, and that contact specific data could be recorded in three different places: individuals, organisations and positions/roles.

We're not sure about the best way to solve this - and share your concern about too much complexity. Also noted that relationships can be extended with custom fields. If you can come up with sponsorship funding we could schedule a project to get this spec'd in a way that would meet your use cases AND work-flow (and work to make it reasonably generalized as well).

4) Assign an employee of an organisation to be the "main point of contact” for that organisation and use this person’s name in all correspondence (mailing labels) etc. addressed to the organisation, and in an online organisation directory

b) ability to specify that you want corrsepondence (in an email/mailing) sent to a relationship to the organisation if this relationship exists, and if it doesn't just to the organisation.

These seem related to "Roles" above, and might best be addressed all together as a project.

[Michael McAndrew]

Hi there,

Many thanks for taking the time to read and respond to these - really very useful.

Has made me think about the different methods required for implementing different functionality and I realise that there are some gaps in my knowledge when it comes to understanding the best way to contribute to OS projects - taking advanatage of patches, backporting functionality slated for upcoming releases, ensuring my customisations don't affect upgrades / can be integrated back into later versions easily, etc.  I know that is general OS stuff, but any advice / pointers on that gratefully received.

In terms of the specifics, I think the best way now is to take up separate items up in individual threads...

Michael