Basic CRM Fields and Custom CRM Entities

CRM stores basic CRM fields that are standard to SiteStacker, as well as custom entities that were configured specifically for your organization.  

Basic CRM Fields

• Title
• First Name
• Middle Name
• Last Name
• Maiden Name
• Nickname
• Suffix
• Gender
• Birthday
• Email
• Shirt Size
• Marital Status
• Wedding Anniversary
• External ID
• Household
• Household External ID
• Additional Email Addresses
• Social Networks
• Phone Numbers
• Instant Messenger
• Addresses

Custom CRM Entities

If a field is not available as a basic field, it can be added as a custom entity field. 

• Entity Groups are general CRM Categories. Entity Groups hold Entities.
• Entities are CRM sub-categories. Entities hold Fields.
• Fields are CRM data points or questions such a "Ministry Assignment" or "When did you become a Christian?" 
• Field Types are various categories that can be used to store data points. Text or Text Area fields are recommended for general fields. 

To view or add CRM entity groups, entities, and fields, go to the CRM component in SiteStacker, click on the Configuration side tab, and then click on the upper tab called Entities. 

Strategy

The structure of your Entity Groups and Entities will become a crucial part of your CRM database. It is important to create a logical structure that will be straightforward and useful for all admins. Your CRM entity structure should be based on the substance of the data points and not on how the admins intend to use the data. Doing so will prevent different departments from collecting the same piece of data but storing it in separate fields.

Examples of correct and incorrect data structure 

Correct: "Marital Status", "Date of Marriage", etc are listed under an entity group called Family, in an Entity called Marriage. Mobilization, Donor Management, etc. both have access to the Family Entity. 

Incorrect: Mobilization wants to collect "Marital status", "Date of Marriage", etc. and create an Entity Group called "Mobilization" and an Entity called "Family" to store the fields. Donor management also wants to collect these fields, so they create an Entity Group called "Donor Profile" and an Entity called "Family". In this scenario, "Marital Status", "Date of Marriage", etc are stored in two places in the database. This could result in out of date or conflicting data points.