5

I am new to CiviCRM and I am wondering what would be best practice regarding the use of contact (sub)types in our organization.

The situation is following: Type of business: coaching and training.

We provide coaching to clients(contacts) so we assign one or more Coaches to a client at the start of a coaching period. This coach(or coaches) could be an in-house coach or he/she could be external. However, coaches could also be qualified trainers in certain areas of expertise. Trainers can offer workshops/courses/trainings to clients but also to coaches and other trainers.

Is it good practice to assign multiple contact sub-types to individuals who are qualified as a coach and trainer and possibly as supervisor as well? Or would a different approach be a better solution?

Many thanks!

Improve this question

3 Answers 3

Reset to default
7

As long as I know it's a good practice to use multiple subtypes in the same contact.

Doing that you can, for example, create different custom fields for each subtype. So your coaches who are also trainers will have the fields for being coaches and in addition the fields for being trainers.

And if in the future, one of your coaches became a traier, you can add him the subtype and automatically will appear the custom fields for it.

So I will recommend it. :)

Improve this answer
2
  • Yes, coaches, trainers, supervisors, etc. all need additional fields and that is why I was considering multiple subtypes. But I wasn't sure if that would fit CiviCRM's structure and assumptions. Thank you soo much for pointing this out to me. Awesome. :)
    – TonV
    Commented May 4, 2016 at 10:58
  • 2
    agree with the general rule of thumb, if a specific sub-type has unique fields, then that is a good reason for sub-type, otherwise see if you can use Tags/Groups or a single Custom Field to do the required and avoid bumping in to edge cases. Such an edge case is the breakage that occured with the 4.6.16 upgrade.
    – petednz - fuzion ♦
    Commented May 16, 2016 at 20:44
3

It will mostly work, however, you are on less travelled paths, so you might bump into issues on some "out of the ordinary" actions. For instance, imports or profiles assume(d) a single contact subtype per contact, so you might end up removing subtypes.

I'd suggest you to test creating a few contacts that have several subtypes and try to export import, see if everything works fine.

More generally, are you going to have custom fields for each of these types? do you need to create specific relationships limited to relations between some subtypes?

If not, it might be easier to stick to groups (or mix with tags), these are much more often used (and battlefield tested) and you won't have any problem having a contact with several groups (or tags)

Improve this answer
1
  • We have a very similar reason to have multiple contact sub-types. Everything seems to be working fine for an Individual to have 2 sub-types. However, we just encountered an issue doing a data import. We are updating fields related to one of the contact sub-types. The result was the elimination of the second sub-type from the contact record. I need to do some more testing to see if I can make the import work without deleting the other sub-type.
    – Ron Gridley
    Commented Dec 30, 2016 at 0:05
-3

UPDATE: What I wrote below is incorrect - I was not up to date (see comments)

Subtypes can be a great way to structure your data. There are however some limitations that you should know about:

  • Each contact (person or organisation) can only be one subtype
  • Subtypes cannot be changed later on

This means that if for example a coach is likely to become a supervisor or trainer at some point I would recommend using custom fields/field sets and groups, tags etc. to structure your information and NOT subtypes.

If you use subtypes you would need to create one contact for each subtype which is most likely not what you want.

Improve this answer
7
  • 1
    I didn't think either of those were the case. We have contacts who are multiple subtypes. Also we can change subtypes when needed.
    – Andrew West
    Commented May 9, 2016 at 9:53
  • Be careful changing subtypes though! If coaches, trainers, supervisors all have different fields - then when you retype one to another you'll loose some data.
    – KarinG - Semper IT
    Commented May 9, 2016 at 12:45
  • I am starting to get a bit confused now....
    – TonV
    Commented May 10, 2016 at 9:51
  • Certain contacts can be a coach, a trainer and a supervisor at the same time. E.g. a trainer could perform coach tasks as well. So those contact types are not mutually exclusive what we are concerned. However, I do not know if (proper use of ) CiviCRM functionality limit sub-types to one per contact. I am wondering what is regarded as best practice by CiviCRM guru's. Many thanks guys!
    – TonV
    Commented May 10, 2016 at 9:56
  • since version 4.1, CiviCRM allows multiple subtypes. (civicrm.org/blog/yashodha/announcing-civicrm-41)
    – Albert V
    Commented May 11, 2016 at 7:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.