Data Hygiene: Centrally Manage and Periodically Review Custom Data and Profiles

In "Data Hygiene: How to Keep Data Clean and Healthy!", we spoke in general terms of the basic steps you need to take to keep your data clean and healthy. In this blog post, we focus on maintaining streamlined profiles and custom data.

Your organization will create a number of custom data sets and profiles.1 If multiple users have permissions to create custom data fields in an uncoordinated manner without clear guidelines, redundancies and waste will most likely occur. Redundancies because similar custom fields could be created for identical or closely related information, potentially with different data types, semantics or input formats. Waste because unnecessary custom fields might be created that will burden the organization (and their constituents) with entering and maintaining this information. Finally, the organization's needs will surely evolve over time, and so will the needs to collect or maintain specific information, the reports that need to be produced, or the forms used for fundraising, event registration and membership maintenance.

In order to alleviate these issues, you might consider appointing a Data Manager to be the sole person with the authority (and relevant CiviCRM permissions) to create custom fields. This will effectively help keep your application screens and forms clear ad relevant. The Data Manager will be the person in your organization responsible for the following:

  • Identifying a clear need for the data and defining how it will be used by asking:
    • Is the information really needed? 
    • How will the fields in a given custom data set be used?
    • How will the information be maintained?
       
  • Creating clearly defined custom data by determining:
    • The types of contacts or records the custom fields will be appropriate for
    • Whether the fields will have a broad applicability, or are they relevant to a specific Contact Type, Event Type, etc.
      For example, a field that stores a person's entree choice at a dinner event should be assigned to the Participant record, and not to the Individual Contact record since the selection is for a specific event (the same contact may make different choices for other dinner events). You can further narrow the scope of the custom data to apply only to event types in which meals are served (this is helpful for back-office event registration as it will prevent custom data fields related to meals from being displayed on events that do not serve meals).2
       
  • Keeping the custom data field and profile structure intuitively organized by:
    • Labeling all fields, custom data sets and profiles clearly and concisely3
    • Using description fields to provide a brief explanation of intended use
    • Grouping fields in custom data sets and profiles by use: 
      For example, you may associate 20 custom fields with Individual contacts, 12 of which relate to an online membership directory. Rather than group all 20 fields in a single custom field set, you may want to split them into two sets - one for the directory-related fields, and a second for more general Individual details. Similarly, there are certain pieces of information that you will always collect for any event registration (e.g. name, address, etc.) - these fields should be included in a generic profile such as "Your Registration Info". For events that include meals, you may also wish to include a profile that allows participants to make an entree selection or to indicate dietary restrictions/allergies - these fields should be included in a generic profile such as "Meal Preference".
    • Maintaining a map of custom fields and profiles and communicating any changes to interested parties
    • Periodically reviewing all custom data sets and profiles and (if necessary):
      • Consolidating custom data sets when possible by moving4 fields and deleting any empty custom data sets
      • Deactivating and perhaps archiving and/or deleting any fields, custom data sets and profiles that are no longer useful

 

1. Users tend to view custom data and profiles as interchangeable, but they are very different: custom data fields store information that is particular to your organization whereas profiles are forms that use custom data fields to collect this information.
2. The scope of a custom field set is one of the few decisions that is irreversible (you will not be able to change it after creating it), so it is important to consider carefully what you want to associate your custom field set with when you start.
3. Labels should always be short and concise, but you can choose different (perhaps more descriptive) labels for profiles  - e.g. you might have a custom data field called "Meal Preference”, when you add the field to a profile, the default label in the profile (what front-end users will see) will be the same, but you may wish to change it to something along the lines of “Please select a meal preference”.
4. Unlike custom data fields, profile fields can't be moved, so profile fields no longer in use should be disabled.