E-mail
We are working on a new CRM System for a regional Council for Voluntary Organisations (CVO), which has many client organisations or Local Infrastructure Organisations (LIOs). Each LIO in turn works to support many client voluntary sector organisations. We can refer to these as L1, L2 and L3 organisations respectively since that perhaps makes more sense for similar structures within a single organisation.
L1 orgs: only require management reports for example to compare activities across L2 orgs but will also act as system admin and help desk.
L2 orgs: will be active maintainers of their data, e.g. updating their L3 orgs' records, logging activities with their L3 orgs.
L3 orgs: will be able to register on their parent L2 org's site and keep their own entries up to date and will have additional permissions on Drupal.
Because the L2 orgs have different contracts with their L3 clients, they should not share data with each other and each set can be thought of as effectively in its own silo. We plan to use the new nestable groups feature: each L2 org would be set up as a group and their member L3 organisations could then be organised into consistent sub-groups such as faith, youth, environment etc.
We envisage a structure like this:
Single Civi installation, single L1 org.
L2 orgs represented as Organisations and as Groups: L2A, L2B, etc.
L3 orgs represented as Organisations, each belonging to their parent L2 org's Group and sub groups: L2A/faith, L2A/youth, L2A/environment, L2B/faith, etc.
However, it's possible some of this will be achieved by something similar to the Multi Org case discussed at http://wiki.civicrm.org/confluence/display/CRM/Multi+Org+implementation+ideas
We would like to be able to give each L2 org a Drupal website on their own domain which they would use for publishing, discussions etc. and which people representing L3 orgs would also sign up to. However, there is no ability to add multiple Drupal installs to a single CiviCRM in the current version and the previously used domain_id has been made obsolete.
Our requirements then, are that L2 users should sign into their own Drupal and be able to edit that and move to Civi still logged in to edit that in the way that normally happens with a 1 to 1 Drupal-Civi combo. This should be achieved either through OpenID or the uniq_id idea discussed on http://wiki.civicrm.org/confluence/display/CRM/Using+an+auto-generated+uniq_id+to+link+CiviCRM+accounts+with+UF+accounts. When in Civi they should be restricted to their own group. Meanwhile it is also proposed that Civi data should be searchable through the Drupal via profile search. This will be very similar indeed to http://www.oxnet.org.uk/civicrm/profile?reset=1&gid=2 and should be achievable by restricting each search based on the L2 group.
2 Comments
Hide/Show CommentsMar 06, 2009
Donald A. Lobo
Having 'n' Drupal installs AND 'n' CiviCRM installs (one for each L2) will make things a lot simpler and easier with our current model
Assuming there are not too many reports that the L1 org needs, this can be a set of custom php files.
If you want 'n' Drupal sites and 1 CiviCRM install, then you will need to share the user table across the 'n' drupal sites and keep the other tables separate. You should be able to use drupal prefixing for this
I'd recommend the first approach, since depending on the total number of contacts it might also be more scalable. We can address the profile search issue once we decide on a model. Also if you have stats on number of contacts for L1 / L2 / L3 and the breakdown of number of orgs in L1/L2/L3 that might nudge the decision one way or the other
lobo
Mar 18, 2009
David Moreton
Having 'n' Drupal installs AND 'n' CiviCRM installs was our initial thought. But, L1 want to have one administrative interface and not log into lots of different sites. There are actually 2 L1 orgs who will share the funding for a single admin post. Probably building to between 15 and 20 L2s who will each have between 300 and 1500 L3s (so let's say 10k L3s) and between 1 and 30 staff logins each. Not all the L2s will be brought online straight away. The plan is to do 6-8 this year and it will be interesting to see how it scales.
L1 will want to be able to e.g. mail all 10k L3s without doing 20 reports,which I suppose you would say you can consolidate in the single set of php files. There will be lots of reports that L1 will want and they'll want to take advantage of the custom reporting feature, building this up over time while both L1 and L2s will also be using the new case/activity search quite a bit - we've been looking at this on our 2.2 sandbox and it's very useful for these organsiations. The ability to generate lots of reports to support funding requests and identify areas for potential intervention (by L2 and comparing L2s) is important. L1 also wants to standardise conventions across the region. So nested groups will be used and L2s will use parallel groups enabling L1 to compare like with like. Currently the way L2s categorise their L3 orgs is often inconsistent and even where similar, different terms may be used - your "Faith Groups" may be the same as my "Religious Organisations" but over there they have "Religious Denominations" + "Faith-led Groups".
Davem