This is very easy to accomplish, and just uses a configuration screen in Drupal.

Drupal uses the page URL to check if you are administering CiviCRM. If you are, the pages are displayed using the CiviCRM administration theme.

It's a good idea to select a flexible-width theme with sidebars. Garland is a good example. The flexible width accommodates CiviCRM displays nicely.

Once the administration theme is selected, navigate to admin/structure/blocks. Here you will see various blocks provided by the CiviCRM module. You can now place these blocks within your administrative theme.

Pay special attention to the visibility settings for these blocks, so that they only appear when using CiviCRM.

In Drupal, there is an additional setting that controls which theme is used to display public CiviCRM pages, for example, event sign-up pages.

There are many different ways of setting up cron, depending on your site-hosting setup. In this example, we are using cPanel, a popular control panel that simplifies website administration.

All cron does is execute the URL that is constructed in the cron file.

The following piece of code does the work:

curl_setopt($ch, CURLOPT_URL, "http://myDrupalsite.com/sites/all/modules/civicrm/bin/cron.php?name=admin&pass=adminpassword&key=01504c43af550a317f3c6495c2442ab7");

The URL contains the information on permissions (the username, the password, and the site key) to execute the cron.php file provided by the CiviCRM module.

Getting cron to work is critical to getting CiviCRM working properly. If you get into difficulties with it, the best solution is to contact your hosting company and seek guidance.

CiviCRM has a fully customizable navigation menu. You can edit this menu to get one-click access to the features you use most.

CiviCRM stores new menu items, and displays them according to where they are placed in the menu tree and what permissions a user may have to use them.

Changing the setting is simply a matter of visiting the CiviCRM administration pages:

CiviCRM components can add to the clutter on the screen. Here we can disable unwanted components and then fine-tune the display of other elements in the contact summary screen.

The words—or sentences—that we want to replace are called strings. In CiviCRM, we can enter the strings we don't want, and replace them with strings we do want.

You need to set a mapping provider—that is a service that will provide you with the visual maps—and a geocoding provider, which will translate your contact addresses into latitude and longitude coordinates.

Geocoding Provider finds latitude and longitude coordinates for each contact address. Mapping Provider uses this information to draw a local map, with a pointer for the contact. Geocode and Parse Addresses do the geocoding work each day, though you can change this in the settings.

Google currently limits geocoding requests to 2,500 per 24 hours. So, if you exceed this limit, Google may not process requests; it may even restrict access to their geocoding service should you continue to break this limit. This is a problem when you have thousands of addresses to process—for example, after a big import of address data.

CiviCRM does not have a tool to place a daily limit on the number of contacts that are processed each day. But you can put parameters into the Geocode and Parse Addresses scheduled job that provide a range of contact IDs to process. You would have to change this each day to work your way though all your contacts.

We will set up an e-mail account that will act as a "dropbox" for messages that we want to file, and link this to CiviCRM.

Each time CiviCRM processes inbound e-mails, it checks the e-mail account you had set up. It then processes each message. If the sender or recipient e-mail address is not held within CiviCRM, it will create a new contact record for each, and will file the e-mail activity.

If the contacts do exist, it files the e-mails as an activity for the sender and an activity for the receiver.

You should consider what activity types you need as part of the planning stage of your CiviCRM deployment. Adding a new activity type in CiviCRM is easy.

Test your new activity type by going to a contact and clicking on the Actions button present at the top left of the contact screen. This will show a drop-down list of available actions. Activities are listed in the first column.

Custom fields need a bit of planning because once you have created a custom fieldset and applied it to an object, you cannot re-edit it and apply it to a different object. For example, let's say you are organizing a boat race. You want to collect information on boat size and boat type. You could choose to collect this custom information for each individual who applies to race, or for each actual participant in the race, or for each team in the race. So if you applied it to an individual contact and then changed your mind and only wanted to collect it for each participant, you would have to recreate the whole custom set of fields.

So you need to think about the following questions:

In this example, we will add a simple custom field to the Phone Call activity. So when a phone call activity is recorded with a contact, the custom field will record if the call was general, a membership enquiry, or an event enquiry.

First we will create a custom data set, and then we will add some custom fields to it. In this recipe, we will add some fields to get data about phone calls.

If you add custom fieldsets to contacts, you will get more options. You can add a fieldset multiple times to the same record. This is useful for recording employment histories or academic achievements.

You can create a custom fieldset for cases, relationships, groups, events, and memberships.

You do not need to have cron running on your site to test this recipe. But, for this recipe to work on your live site, you must have cron running.

You will need to know how to set up and use mail templates within CiviCRM.

First we will set up the activities we want to schedule and then we will create the Scheduled Reminder for each activity. Every Scheduled Reminder uses a mail template. We will configure the mail template to accomplish the original activity.

CiviCRM will now send out your reminders at the scheduled test times. Check your test e-mail account for incoming mails at regular intervals.

The Schedule Reminders system does not automate your workflow.

If you look at the Activities tab for your test contact, you will see that the status is still set to Scheduled even after the reminder has been sent. This is because Scheduled Reminder is sending out a reminder about the activity, not accomplishing the activity itself.

You may wish to investigate writing a module that switches the activity to the status Completed once the reminder is sent.

CiviCase does not have a user interface for configuring CiviCase types. Instead, we create all the activity types and relationships that we need, and then we create an XML file that generates and schedules these activities when a case is opened. The CiviCase type we are going to create will handle three activities:

We will use the XML file to also generate the relationship types associated with the employment record. These are:

The XML code does all the work for us once it is set up. Let's go through the structure. This provides the name of the case type that we will use:

<?xml version="1.0" encoding="iso-8859-1" ?>
<CaseType>
<name>Staff Record</name>

We have a section called ActivityTypes (note the plural!). It is a container for each activity type that is going to be associated with the Staff Record case.

<ActivityTypes>
<ActivityType>
      <name>Open Case</name>
      <max_instances>1</max_instances>
    </ActivityType>
</ActivityTypes>

CiviCase always starts with <ActivityType> named Open Case.

<max_instances> tells CiviCase how many instances of the activity to create. As a case is opened only once, there is only one instance.

<ActivityType>
    <name>Contract acceptance</name>
    <max_instances>1</max_instances>
</ActivityType>
<ActivityType>
    <name>Annual appraisal</name>
</ActivityType>
<ActivityType>
    <name>Exit interview</name>
    <max_instances>1</max_instances>
</ActivityType>

The three activity types that we will use in our CiviCase are described next. You can see that the activity type named Annual appraisal does not have a <max_instances> tag. This is because annual appraisals take place each year and there is no defined maximum.

Now that we have set up what activities we will use for our case, we can schedule some of them on a timeline. For this, we create another section, called ActivitySets, in the XML file.

<ActivitySets>
<ActivitySet>
<name>standard_timeline</name>
<label>Standard Timeline</label>
<timeline>true</timeline>
<ActivityTypes>
<ActivityType>
<name>Open Case</name>
<status>Completed</status>
</ActivityType>
<ActivityType>
<name>Contract acceptance</name>
<reference_activity>Open Case</reference_activity>
<reference_offset>7</reference_offset>
<reference_select>newest</reference_select>
</ActivityType>
</ActivityTypes>
</ActivitySet>
</ActivitySets>

Here we have the section called ActivitySets. It is a container for one or more instances of ActivitySet.

ActivitySet is a set of scheduled activities that CiviCase will generate when our Staff Record case is opened. When the case is first generated, CiviCase uses the <standard_timeline> activity set to generate the initial set of activities. You can have additional ActivitySet instances that use a different timeline. This is used to create activity branches within a case. In our example it could be the case that if an employee has a poor annual appraisal, we need to generate another set of activities to deal with the outcome. We can do this by having it configured in our XML file and applying it in the Add Timeline section of the CiviCase screen.

Within each <ActivitySet> instance, we have <ActivityType> again, and we have some tags to schedule each type.

<reference_offset> is the time in days that the activity will be scheduled. The offset is measured from whatever activity is entered in the <reference_activity> tag.

If the referenced activity has multiple instances, such as a training course, then we use the <reference_select> tag to pick the newest instance of the activity. If we do not want an activity schedule, we do not include it in <ActivitySet>.

Finally, we have a <status> tag that allows us to see the initial status of the activity when it is scheduled.

In our previous example, we have set the Contract acceptance activity to be scheduled seven days after the Open Case activity.

<CaseRoles>
<RelationshipType>
<name>Human Resources Manager</name>
<creator>1</creator>
</RelationshipType>
<RelationshipType>
<name>Line Manager</name>
</RelationshipType>
</CaseRoles>

Finally, there is an XML section where we can create our relationships for each case. Each relationship we create becomes a role within the case.

This is just a very simplified example of what can be achieved using CiviCase. There are other ways you could apply the same principles: training schedules, volunteer induction programs, membership induction programs, as well as traditional casework applications.

There are two stages to localizing CiviCRM. First we will download and install an interface translation and then we will configure CiviCRM using the Localization admin screens.