CiviCRM Community Forums (archive)

Hi – I am part of the core team establishing a CiviCRM for the NZ Green Party. We are 'mapping' our party's internal arrangements and positions/roles (not ACL roles!) into CiviCRM and are looking for some guidance on best practice in terms of using; Groups, Tags, Organisations, Smart Groups, Relationships (and nested groups since they appear imminent)

I have read and re-read much of the documentation and discussions but see conflicting advice being offered for similar situations (eg do volunteers get set up as Tags or Relationships etc).

[Note to try and avoid confusion around terminology I have capitalised the first letter of terms, e.g. Relationship and Organisation, when referring to CiviCRM terminology]

We are a simple organisation in the sense that we have a national body, provinces and branches; ie we are not dealing with a multi-organisational body as is being discussed elsewhere at present.

Members only belong to one branch, each branch is only in one Province etc.

At each level of the Party there are common committees and office holders; ie each branch will have its Membership Secretary, and there is a national MembSec. All provinces have a Rep on the Exec Committee and one on the Policy Committee.

At each level there are also additional positions/roles that are unique to particular branches or provinces. There are a plethora of positions/roles that are unique at the national level.

Ideally we want

• permissions belong to positions/roles, e.g. the permissions are set for a Memb Sec and someone with that role therefore has a default access based on their role
• positions/roles – and hence permissions - will be dependent on party membership, ie if someone resigns, they cease in their position/role automatically and hence lose their permissions
• ability to easily view the history of any particular positions/role ie be able to check back and see who was in that position/role in previous years (helps overcome loss of institutional memory if we know and can contact person who did the job previously)
• groupings of people to feed in to our Mailman system, e.g. so when a Treasurer is replaced the new contacts email details are provided to our Mailman for the Treasurers' e-group (and we have an approach for doing this so don't focus on this aspect please ;-) but very happy to know if others have cracked this)

We want to map our Party in to CiviCRM so that we can cut and slice both horizontally and vertically. Some of our more direct goals from this exercise are

• view all the position/roles that a person has within the party
• view all the officeholders for any of our branches/provinces
• identify all officeholders throughout the organisation
• find all the (e.g.) Treasurers throughout the party
• find only the (e.g.) Treasurers operating at a particular level eg province
  

OPTION A
The approach we are trialling involves

• setting each branch and province as a CiviCRM Organisation
• using Relationships to create the structural linkages between these components of the party [Branch of : Province for]
• using Relationships between the individual and the Organisation to link officeholders to their Committees [ Officer for 'Branch X': Exec of 'Branch X'] and using 'custom fields' to define each of the actual positions [Treasurer : MembSec : Sec : Convenor etc]

[Note the use of Organisations for branches etc is only to provide structure for officeholders (and employees). Members (and supporters etc) will be allocated to the smallest geographical unit that is used in our electoral system – 'meshblock' – hopefully via an address lookup. Clusters of 'meshblocks' then define 'branches', clusters of 'branches' define 'provinces' – so we are not intending to actually 'join' members to our internal party Organisations.]

We would use Custom Fields to create the specific types of roles/offices ie the Relationship of [ Officer for 'Branch X': Exec of 'Branch X']  has the Custom Fields for  'positions' containing 'multiple choices' including 'treasurer, memb sec, convenor' etc.

We will need to write code so that these Custom Fields:Positions show on the same page as a persons Relationships (or on their dashboard).

Representatives
There are also people who represent their branch on committees at the province level, and others who represent their provinces at national level. This doesn't look like it works as easily via relationships because the 'rep' has a relationship both to the entity they represent, and the committee they participate on. We look at dealing with this by creating the relationship between the person and the body they represent [Rep for : Rep on behalf of] – and then again between the individual and the body the rep 'on' [Rep on : Rep body].

Issues

• applies 'start/end date' to all the positions
• can create 'other' within 'custom field' as a 'text' field for all those odd ad hoc positions that individual branches may have e.g. 'asset manager'
• Relationships aren't (yet) available in Advanced Search

OPTIONS B-Z
There are obviously other ways we could approach this eg treat 'officeholders' as an attribute of an individual and therefore use 'tags' and then use 'smart groups' to create the groupings of 'all treasurers in the party' and 'all officeholders in a province'.


RELATED ISSUES
Related to this is the issue about how we treat volunteers. I have seen recommendations that we use 'tags' and other recommendations to use 'groups' but we could equally use the above approach in order to first capture 'volunteer' as a 'relationship' and then use 'custom fields' to differentiate the many ways that people may be offering to volunteer.

We are keen to benefit from your collective wisdom before we go to far down any particular route!

Hey Lobo - am drafting some comments on the permissioning discussion and noted that how you tackle this may influence the effectiveness of the approach I have outlined taking. One key issue is how do we set it up so that Permissions are associated with Positions rather than the people in those roles. As mentioned elsewhere, Positions exist even when vacant.
Looking forward to the considered response (especially as it has been relatively quiet since I posted).

Hey Lobo - have made some comments on the permissioning discussion and noted that how you tackle this may influence the effectiveness of the approach I have outlined taking. One key issue is how do we set it up so that Permissions are associated with Positions rather than the people in those roles. As mentioned elsewhere, Positions exist even when vacant.
Looking forward to the considered response (especially as it has been relatively quiet since I posted).

Hi Peter - I've been reading through and absorbing your requirements. There are currently several CiviCRM implementations out there which are handling similar political party use cases. However, I think they involve somewhat cumbersome setups (e.g. several hundred Smart Groups to define the member segments by region, and corresponding ACL groups to hold the permissioned staff members).

The multi-organization enhancements currently under discussion  - with the addition of functionality to pass in parameter(s) to smart groups - will allow much cleaner and more intuitive implementation of your requirements. Can you point me to your comments on the permissioning discussion - somehow I'm not seeing them :-( .

I've also made some notes about specific pieces of your requirements - mostly some questions and observations about fit to currently available (in 1.8 ) functionality. Hopefully these are helpful in moving things forward...

---

"Officeholder" options (Officer, Exec, ....?) vs. Postions (Treasurer,
Member Sect etc.)... How do these two relate to each other? Could each
be defined as separate relationship type? Would you be permissioning
on the Officerholder property, AND/OR permissioning on the Postition?

Custom Relationship fields are NOT supported in Advanced Search.
Hence, if we can use relationship type to define Positions, that might
make things easier. (Maybe a Tag is enough for the "Officeholder"
property if you don't need history for it).

Also, you can't currently search on "expired" relationships - so
finding past Treasurers might not be easy/possible w/o custom code or
a custom report.

How will meshblock / branch / province info be stored for each
"member".  I'm asssuming you'll need to create smart groups based on
these value(s) - and then assign permissions to view/edit members in
each smart group to a role.

We currently don't support using Smart Groups as an ACL group - so you
can't globally link a role and it's permissions to a relationship
type. EXAMPLE: You can create a Smart Group of all "Treasurers" - but
you can't assign permissions to that group.

Relationship search IS supported in Advanced Search. However,
searching for Treasure of a specific province or branch might that way
might be tough  - since you'll have to manually enter the organization
name (e.g. Nelson North Branch).

Representatives - So would committees also be Organizations based on
the approach described? What about making them static groups -
representatives just get put in the groups (and implicitly represent
the branch, province etc. that they are "related" to).

Volunteers - depends how you want to expose this and what data you
want to collect and retain for volunteers. If self-signup, then
group(s) and / or custom fields are "exposable" in profiles while
relationships are not (other than Employer). A Volunteer custom data
group (which can then take advantage of the multiple instance feature
in 2.0) might be best. The custom field "group" might have the
following fields:

• Volunteer Activity - select from a list?
• Skills
• Availability (days / times available)
• Volunteer Start / End Dates
• Volunteer Coordinator Notes
• Rating (INT - 1-5 radio buttons)
• etc.

Check out the CiviVolunteer discussion for more ideas on this:
http://wiki.civicrm.org/confluence/display/CRM/CiviVolunteer%2C+CiviCommittee

"Officeholder" options (Officer, Exec, ....?) vs. Postions (Treasurer,
Member Sect etc.)... How do these two relate to each other? Could each
be defined as separate relationship type? Would you be permissioning
on the Officerholder property, AND/OR permissioning on the Postition?

My view is that Officeholders are appointed to Positions. We have a 'role' of Treasurer - John gets appointed to that role and therefore becomes the 'officeholder'.

Permissioning should relate to the Position. When someone gets appointed to the Position i.e. become the Officeholder, then they 'inherit' the permissioning associated with the Position.

Ideally we will also be able to see the history of people who have filled a Position.

Relationship search IS supported in Advanced Search.

I think I was thinking about searching the Custom Fields we have created to extend Relationships to cover our 'Positions'.

The treasurer might get some 'extra' permissions on financial information which 'officeholders' do not get by default

Hey Lobo - I wasn't meaning that 'officeholders' would all have the same level of permissions - but maybe you didn't either. Had a draft post on permissions awaiting comments from Chris but have gone ahead and posted at http://wiki.civicrm.org/confluence/display/CRM/Multi-Organization+Support+in+CiviCRM?focusedCommentId=14475#comment-14475

Thanks Neil - can i just drag some more detail from you. Can you detail how your Relationships approach is used. Are you using Relationships to establish a link between the person and the relevant 'body corporate' (ie committee or whatever) and then using Custom Fields to specify the actual Position. This is what we were looking at doing but it fails because the Start/End date is for the 'relationship' and therefore isn't flexible enough to deal with John being a Branch Treasurer (appointment ends June 08) and a Volunteer Coordinator (no end date). Also doubt we can track history of who had which roles in past. cheers

Thanks Neil - we were trying Custom Fields to extend Relationships so we didn't have to create so many Relationships but will definitely consider your approach both because it deals with the 'start end date' and the Advanced Search issue (ie the Search only shows the Relationship exists but not the actual position we created through the Custom Fields). And yes I had been looking to use the 'disable' as a way of keeping history so thanks for pointing out they will show up in Search.

Ok so am trying out the approach of not using custom fields. When i try an Advanced Search in Relationships to find all 'Convenors for' with % in Target Contact field I get a list of all my Convenors - but it does not show which Organisation (Branches or Provinces) they are Convenors of. So set them as a Smart Group but still doesn't show that. So then went to export but the field choices only seemed to cover address etc type info and not Relationships.
Am I missing something obvious or is the goal of being able to view a list of who all the convenors are (or who all the officeholders are in a particular Branch) going to require some backend work?