Answers.Body: <p>The best architecture would be to create Organisation sub type and then have relationship with subtype contacts. This would be easy to related contacts such as in your case. Adding relationship will be consistent and easy to add custom ACL.</p>
  
  <p>If you want to use custom fields than you will need to create multi-value custom field of type contact reference for each contact sub type. This field will pull contact(s) from specific contact group which can be smart group or normal group having contacts of specific contact type. In this way you can create hierarchy of relationship using contact type.  </p>
  
  <p>But i believe you will need to add some custom code i.e either building custom report or restricting contact CRUD operation for user belonging to specific denomination. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-12T09:33:22.120Z
Answers.Text: Thanks. So you're saying the best option is not to use custom fields, just relationships? I can set that up for the existing data. Is Webform Drupal that petednz mentions then the thing I need to learn to build a more friendly interface for my users, so they can choose from a drop down of the denomination organisation subtype and have the relationship created automatically?
Answers.UserDisplayName: somnolentsurfer
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-12T10:07:02.993Z
Answers.Text: Both are good options to implement. Its your call based on how much you want to customize screen like make the UI form simpler so that user don't have to follow 10 steps when he wants to create/update a contact., Reports. So using combination of Custom fields and relationship will be an good idea. Custom fields will be easily available on screen and relationship will be useful to structure your org and also to have historical logs about relationships. But you may need to add bit of coding to make simple for user.
Answers.UserDisplayName: Pradeep Nayak
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-09T16:01:50.427Z
Answers.LastActivityDate: 2018-10-09T16:01:50.427Z
Answers.UserDisplayName: Pradeep Nayak
Body: <p>Apologies if this isn't the best place to ask, I'm completely new to CiviCRM and could do with some advice on the best way to store custom data.</p>
  
  <p>I'm building a database of churches. For each church I want to record the denomination. Depending on the denomination, there are other details I also want to record. For example, for anglican churches I want to record the diocese, and for some dioceses I want to record further administrative subdivisions that churches belong to. But other denominations don't have those structures, and might have completely different ones. And some churches belong to more than one denomination, so might need the full structure details for two or even three of them.</p>
  
  <p>As far as I can see there are three different ways I could organise that data:</p>
  
  <ol>
  <li>Using custom fields. I could create a multiple record fieldset allowing me to record more than one denomination for each church. But then how would I store the different structures for the different denominations?</li>
  <li>Using tags. I could create tags for every different level of every denomination in the database, so for example a church could be tagged with 'Anglican, Leeds Diocese, Bradford Episcopal Area'. But then the tags would exist for any contact in the database, not just churches, which could lead to a lot of clutter and confusion among users, particularly as the database grows.</li>
  <li>Using relationships. I could create organisational contacts for denominations and dioceses, and then use a relationship to associate, e.g. X church is a member of Methodism, or Y church is a member of Southwalk Diocese which is a member of Anglicanism. But I think that will also be confusing for users, particularly when adding a church from a new diocese/denomination, and could lead to lots of shadow contacts that only exist for the purpose of categorisation rather than as actual contacts.</li>
  </ol>
  
  <p>I'm leaning towards custom fields, but the only way I can see of getting the result I want would be to have a different contact type for each denomination, and then a fieldset for the relevant structural information on each contact type. Which would mean the denomination would have to be filled in by users in a box headed 'Contact Type' instead of a box headed 'Denomination', and that it would be mixed in with other non-church contact types.</p>
  
  <p>What would be the best practice method? </p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-10-09T18:38:53.143Z
Comments.Text: is this Drupal or WP or Joomla. Asking because Webform Drupal lets you side step a lot of constraints in civi about creating complex relationships etc in a single form
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-10-12T09:14:00.247Z
Comments.Text: I'm on Drupal. Complete novice at that too though!
Comments.UserDisplayName: somnolentsurfer
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-10-12T23:33:56.103Z
Comments.Text: I would say it is definitely worth wrapping your head around what webform_civicrm lets you do - has been a lifesaver for us so often
Comments.UserDisplayName: petednz - fuzion
Tags: <custom-fields><relationships><tags><best-practice><contact-types>
Title: Tags, relationships, or custom fields to record custom data?
ThreadText: # Tags, relationships, or custom fields to record custom data?
  
  (Asked by: username_0 on 2018-10-09)
  
  Apologies if this isn't the best place to ask, I'm completely new to CiviCRM and could do with some advice on the best way to store custom data.
  
  I'm building a database of churches. For each church I want to record the denomination. Depending on the denomination, there are other details I also want to record. For example, for anglican churches I want to record the diocese, and for some dioceses I want to record further administrative subdivisions that churches belong to. But other denominations don't have those structures, and might have completely different ones. And some churches belong to more than one denomination, so might need the full structure details for two or even three of them.
  
  As far as I can see there are three different ways I could organise that data:
  
  1. Using custom fields. I could create a multiple record fieldset allowing me to record more than one denomination for each church. But then how would I store the different structures for the different denominations?
  2. Using tags. I could create tags for every different level of every denomination in the database, so for example a church could be tagged with 'Anglican, Leeds Diocese, Bradford Episcopal Area'. But then the tags would exist for any contact in the database, not just churches, which could lead to a lot of clutter and confusion among users, particularly as the database grows.
  3. Using relationships. I could create organisational contacts for denominations and dioceses, and then use a relationship to associate, e.g. X church is a member of Methodism, or Y church is a member of Southwalk Diocese which is a member of Anglicanism. But I think that will also be confusing for users, particularly when adding a church from a new diocese/denomination, and could lead to lots of shadow contacts that only exist for the purpose of categorisation rather than as actual contacts.
  
  I'm leaning towards custom fields, but the only way I can see of getting the result I want would be to have a different contact type for each denomination, and then a fieldset for the relevant structural information on each contact type. Which would mean the denomination would have to be filled in by users in a box headed 'Contact Type' instead of a box headed 'Denomination', and that it would be mixed in with other non-church contact types.
  
  What would be the best practice method?
  
  **Tags:** custom-fields, relationships, tags, best-practice, contact-types
  
  > **Comments:**
  > **username_1**: is this Drupal or WP or Joomla. Asking because Webform Drupal lets you side step a lot of constraints in civi about creating complex relationships etc in a single form  
  > **username_0**: I'm on Drupal. Complete novice at that too though!  
  > **username_1**: I would say it is definitely worth wrapping your head around what webform_civicrm lets you do - has been a lifesaver for us so often  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-10-09. Score: 0 | Accepted answer
  
  The best architecture would be to create Organisation sub type and then have relationship with subtype contacts. This would be easy to related contacts such as in your case. Adding relationship will be consistent and easy to add custom ACL.
  
  If you want to use custom fields than you will need to create multi-value custom field of type contact reference for each contact sub type. This field will pull contact(s) from specific contact group which can be smart group or normal group having contacts of specific contact type. In this way you can create hierarchy of relationship using contact type.
  
  But i believe you will need to add some custom code i.e either building custom report or restricting contact CRUD operation for user belonging to specific denomination.
  
  > **Comments:**
  > **username_0**: Thanks. So you're saying the best option is not to use custom fields, just relationships? I can set that up for the existing data. Is Webform Drupal that petednz mentions then the thing I need to learn to build a more friendly interface for my users, so they can choose from a drop down of the denomination organisation subtype and have the relationship created automatically?  
  > **username_2**: Both are good options to implement. Its your call based on how much you want to customize screen like make the UI form simpler so that user don't have to follow 10 steps when he wants to create/update a contact., Reports. So using combination of Custom fields and relationship will be an good idea. Custom fields will be easily available on screen and relationship will be useful to structure your org and also to have historical logs about relationships. But you may need to add bit of coding to make simple for user.  
  
  ---
  
  