Every new install of CiviCRM starts out fresh and clean, with only the built-in data fields. However, as every organisation has its own data needs, we often find ourselves adding more and more custom fields to this. This can easily start to clutter your contact views.
An important way to avoid this and manage your custom data fields is to create relevant contact subtypes and assigning your custom data fields to those subtypes.
As a simple example, as a training event organizer, say you are keeping track of participants, speakers, and support staff in the same database. You may want to create custom fields for the speakers to keep track of their areas of expertise, for the support staff to monitor what roles they have received training for, and for participants to make sure that their knowledge of the training languages is recorded. Using subtypes, you can then easily assign these custom fields so that they only appear for that particular kind of contact. If we then figured that we also wanted to keep track of the language skills of speakers in the same way as for participants, we could just assign the same custom data field to this subtype as well. Have a speaker who is also part of the support staff? Not a problem - we can assign multiple subtypes to each contact.
What steps should I follow to create and manage subtypes and your custom data fields?
Creating your subtype
- In CiviCRM, go to to Administer --> Customize Data and Screens --> Contact Types
- Click "Add Contact Type"
- Name the subtype and choose which of the basic contact types it should apply to (for my example above, all three would apply to individuals, but you may also be interested in subdividing organizations or households)
Creating and assigning your custom data fields
- Go to Administer --> Customize Data and Screens --> Custom Fields
- Click on "Add Set of Custom Fields"
- Name your set, change the order if necessary, and fill out the help fields if useful
- For the "Used For" drop-down menu, select the basic contact type that was chosen as the parent type of your subtype.
- You should see your new subtype in the list that appears. If you want to apply the custom data field to multiple subtypes, hold down CTRL (Win) or CMD (Mac) and select all the subtypes.
- Save the set and add the custom data fields for it.
- You are able to go back and change the subtypes at a later stage by clicking on "More --> Settings" next to the data set. As of 4.4.3, it is necessary to have first assigned it to a subtype (if you have assigned it to the basic type, you are not able to use the administration interface to restrict the set to a subtype).
Assigning subtypes to your contacts
You can assign subtypes either on creating a contact, or later on by editing it. After assigning a subtype, its corresponding custom data fields should appear.
When creating the contact
Go to Contacts --> The basic contact type you are creating (e.g. "New Individual" --> Your newly created subtype (e.g. "New speaker")
When editing a contact
- It is not possible to use the quick edit functionality from the contact overview. Instead you need to click on the "Edit button" from the main contact view.
- Under "Contact Type," select your new subtype. If you want to assign more subtypes, just make a new selection. If you need to remove a subtype, just click on the X to the right.
Things to keep in mind:
- Creating and assigning subtypes has the added benefit of being a practical way to subdivide your contact database for general purposes, and can be more practical for this purpose than groups and tags. For example, you are able to easily search by subtype from the basic search screen.
- Every time you create a new custom data field, think through who this is actually relevant for. Don't assign it to the entire contact type - it might well be sufficient to restrict it to a subtype.
- It is better to initially be restrictive with which subtypes to apply custom fields to. You can easily assign a custom field to more subtypes later on, while removing it from a subtype can be more of a hassle if it has been used for any contacts of that subtype. This will ensure that you do not clutter contact subtypes unnecessarily.
- Don't wait with creating subtypes. Plan your data structure at an early stage - keeping your contact views as clutter-free as possible is important to avoid confusion among teams accessing and editing data, even in the smallest of teams!
This is a really important consideration for a new install, as it's very difficult to put things right after a system is loaded with contacts and custom data has been created. If you get it wrong at the start, or don't think about this, it can be tough to sort out later. It's easy enough to reassign contacts to new contact types. But to first unload the custom data, removing and reassigning the custom data to different contact types and then re-importing the custom data is definitely not an attractive option. I've been there...
Interesting use case and I can see how this would be useful for your situation, good work. Custom data field "scope" is an important concept and subtypes are an effective way of managing custom data scope.
However, you also seem well organized wheras many organizations I am familiar with are not. Subtypes become a burden and hassle rather than an asset for them and a clumsy crutch for users unfamiliar with Civi.
Also note that when using Civi public forms (registration pages, contribution pages) a the public cannot easily select their subtype according to my most recent experience. Whereas Groups (through Profile settings) are easily configured as is custom data fields.
There are no "Smart Subtypes" like there are Smart Groups. Subtypes such as "Donor" or "Member" or "Event participant" are usually inappropriate for subtypes and more useful as Smart Groups. (I'm not suggestion you are doing this, just a warning to others).
Search and report support is also more widespread in Civi for groups and tags... than for subtypes.
The more we can encourage people to use sub types, custom data, and smart groups the better. We also need to continue to discourage the use of tags and (static) groups.
You do a great job of explaining why sub contacts are important and how they can be utilized.
Tags and static groups have their purpose, albeit a limited one. Although I agree with the spirit of your post that tags and static groups are probably overused.