How data is organised

This chapter covers the main building blocks that CiviCRM uses to store data, and describes their intended usage. It is recommended reading for working out how you should organise your data in CiviCRM.

A successful CiviCRM installation depends on having your data stored in the right place. This chapter goes through all of the places that you can store data and helps you to understand why you would store data in one place and not another.

Equally important to understanding the different building blocks presented below is understanding how they can be extended using custom data (described in the next chapter).

Contacts

Contacts are the main building block of CiviCRM. There are three types of core contacts in a standard installation:

Individuals
Organisations
Households.

Contacts hold contact information, including:

name, nickname, greeting, title
website, email addresses, phone numbers, IM account name
addresses
communication preferences (which methods do they prefer being contacted by, and which methods do they not want to be contacted by).

All of the other building blocks of CiviCRM such as relationships, contributions and groups are connected to contacts in some way, so you can see events that a contact has attended, or what contributions they have made.

You can define further contact types to suit your needs, for example "students", "farms" or "churches". Each contact type you define is based on one of the three core contact types. For example, students would based on individuals, and farms could be based on organisations, or perhaps on households, depending on your situation.

A contact can be only one contact type. For example, they can't be a student and a teacher (but contact types are not the only way to differentiate your contacts).

All users of your content management system are also stored in CiviCRM as individuals. Their contact record in CiviCRM is linked to their user record in the CMS (Drupal or Joomla!). Note that only individuals can be linked to user records in your CMS. Organisation and household records in CiviCRM cannot be directly linked to user records in your CMS.

Relationships

Relationships are a way to connect two contacts to each other. Two out-of-the-box relationship types in CiviCRM are the "employer - employee" and the "parent - child" relationship types.

There are always two ways to describe a relationship in CiviCRM: one describes the relationship of A to B, and the other of B to A. For example, Adam is Bernard's son and Bernard is Adam's father. Sometimes both descriptions will be the same: Charlie is Diane's friend and Diane is Charlie's friend.

CiviCRM comes with a number of relationship types in the standard installation. You can define further relationship types to meet your needs, for example you might define a relationship type of "vicar - church".

It may be helpful to compare relationships to groups: relationships connect two contacts, while groups contain two or more contacts who have something in common.

Groups

Groups are useful to identify two or more contacts with something in common. For example, the advisory board of your organisation could be modelled as a group.

Groups are often used as mailing lists. For example, you could create a group containing all your newsletter subscribers, then use the group to send an email newsletter.

A group can be the "child" of a "parent" group. When a group is a parent, selecting the contacts in that group will also select contacts that are in the child group.

For some groups, such as your advisory board, you might want to capture other types of relationships than a simple "belong to" (eg. president, vice-president, member, substitute). Instead of creating a group, you might want to create a new type, "board", and a contact, "advisory board", then add the members of the group as relationships to that contact. For mailing purposes, you might want to create a smart group with all the related individuals (no matter the type of relationship) of that board.

Groups are also used in many other situations. For example, a search can be saved as a group (or a smart group) and groups can be used to provide permissioning. To find out more about groups and how they are used, read the chapter on groups and tags.

Activities

Activities are a key concept in CiviCRM. Activities track interactions between the organisation and its clients or contacts at a specific point in time. All of CiviCRM's components make extensive use of activities, such as to record contributions, event attendances, membership subscriptions, and emails.

You can create additional activity types to define specific activities that your organisation carries out, for example, "completed annual survey".

Activities have the following characteristics (most of these should be filled in for each activity and those in bold on the form are required):

time: activities always happen at a certain point in time
status: is the activity scheduled, completed, cancelled, etc.
added by: the person who added this activity, or the contact if they carried out the activity themselves via the website
assigned to: the person (usually within your organisation) that carried out (or will carry out) the activity (this is often the same as the person who added the activity)
with contact(s): the contacts in your database that are the subject of the activity.

Compare activities to groups. Would you choose activities or groups to record a membership pack that was sent to a contact? You could add all contacts that have received a membership pack to a group "received membership pack", but it would probably be better to record this as an activity. That way, you can record when the membership pack was sent, who sent it, any notes about what the person requested, and so on. You could also use the activity to schedule sending membership packs by setting the status to scheduled.

Contributions

Contributions are a type of activity, and a fundamental concept of CiviCRM. Contributions are used whenever there is a financial element to an interaction. A contribution will be created for each donation or campaign contribution, for paid events and for membership fees.

CiviCRM comes with several predefined contribution types (including donations, campaign contributions, membership fees and event fees). You can define additional types to meet your needs.

Contributions have different statuses which reflect the process of receiving a contribution. Some of these statuses are are set automatically by payment processors.

For more information, see the section on CiviContribute.

Memberships and membership types

Memberships are another type of activity. As well as the usual activity fields, they contain extra fields used for tracking memberships, such as start and end dates.

CiviCRM allows you to define different membership types with fees, start and end dates, and other settings. You can define the types that meet your organisation's needs.

Memberships can be renewed. When this is done, the start and end date will move on by the specific time period but the join date will remain the same (i.e. the same as the first membership start date).

If the membership has a fee associated with it, this will be recorded as a contribution and linked to the membership.

For more information see the section on CiviMember.

Events and event attendances

CiviCRM has a building block for events which contains fields to add events and give these events, times, locations, fees and other information.

When a contact registers for an event, a participant record is created linking the contact to the event. A participant record is a type of activity.

For more information see the section on CiviEvent.

Cases

Cases are a way to logically connect a series of activities. You can define different case types and associate a predefined series of activities with them. When you create a new case, you typically create a series of scheduled activities that need to be completed as part of that case. As the case progresses, you can record new activities, or series of activities, as part of the case.

For more information see the section on CiviCase.

your comment:

name :
comment :