In this section, we're going to delve more deeply into the functional areas supported by CiviCRM. We'll be reviewing the kinds of questions to ask, often of a more technical nature, that will help in planning your implementation.
CiviCRM has three basic types of contacts: Individuals, Households, and Organizations. The fields and kinds of relationships that can be created may vary by the type of contact. For example, individuals have first and last names, current employer and job title, while organizations have an organization name, a legal name, and current employees. CiviCRM's rich model for storing address, phone, and e-mail information is shared by all three types of contacts.
In some cases, it is possible to identify unique constituent subtypes that do not overlap with other types. Contact subtypes in CiviCRM extend the three basic contact types, allowing you to further segment your constituent records. A contact may only be assigned a single type/subtype, so these must be constructed such that there is no ambiguity or possible crossover between types. For example, students at a primary school are never also teachers, though at a university it is possible for an instructor to also be a student. The former could warrant construction of two subtypes, while the latter example would not. Try to identify such subtypes early in your process, as it will help structure relationships and keep your data organized. Special relationship types can be set up that only allow a contact subtype at one or both ends of a relationship, like Teacher and Student subtypes being the only ones allowed in a "teaches/is taught by" relationship. Custom data fields may also be created that apply to a single or multiple subtypes, such as the classroom of a primary student. These fine-grained approaches to data fields and relationship types help reduce clutter (the field and relationship types are not visible unless they apply to the contact type) and help improve data consistency (staff are not inclined to record information that doesn't apply for a certain contact type).
After identifying the types of constituents your organization interacts with (for example, granting agencies, staff, clients, volunteer lawyers, and donors at a free poverty law clinic), determine the data to be tracked for each type. At this point, we're primarily interested in identifying the kind of information that the organization tracks for the individual, organization, household, or any subtypes you've constructed. Since this data is attached directly to the contact record, it generally will consist of attributes about the contact, such as their expertise or volunteer interests, rather than their interactions with your organization, like what they did the last two times they came in to volunteer.
Different groups of constituents will often need to have different types of custom fields used to track information about them. For example, whether donors prefer a single annual tax receipt or one per donation, the policy area interests of an organizational contact, and what an individual's volunteer interests are. Before trying to capture these needs either through interviews or examining existing data, it can be helpful to review the material in later chapters on how these fields will be implemented, for example as text or integers, Yes/No checkboxes, single or multi-select fields, and so on.
Your organization probably sends or could benefit from sending blast or bulk e-mails, such as newsletters and appeals. CiviCRM is good at sending e-mails to lists and tracking which ones are opened, clicked through, and forwarded. Ask the following questions about your bulk e-mail needs:
- What bulk e-mail lists exist and are planned?
- How are contacts added to the list? Ensure that appropriate authorization is being acquired for every bulk e-mail sent to every e-mail address. Also, make sure there are appropriate mechanisms in terms of prominent website blocks and subscription enticements so that you have enough list growth to feed your contact funnel.
- How many custom templates with graphics are required for each e-mail list? Sometimes different communication products are mailed to the same list with each requiring its own template.
- How big is each list and how often is it mailed? This may affect server sourcing in terms of CPU resources, bandwidth, or perhaps e-mail caps.
- How important are high deliverability rates and white listing? Paid services not included in CiviCRM can be set up to assist in monitoring whether various hosts and domains like AOL, Hotmail, Gmail, or Sympatico are blocking your e-mails. Issues can be resolved either by using tools to assist in making your e-mail content more compliant with their ever-changing anti-spam rules, and/or through discussions with them. Monitoring whether your domain or server gets included on various spammer blacklists and promptly dealing with issues in this area may also be important for your organization.
Will your CiviCRM installation need to accept online payments? If you want to accept online payments for events, memberships, or donations you'll need to set up arrangements with an online payment processor such as PayPal, Google Checkout, or Authorize.net. Some of these require your users to go to pages on a different site. These are generally easier to set up and potentially reduce your risk and liability, though they provide a poorer user experience and will cheapen the feel of your site. CiviCRM also supports fully integrated processing where the user never leaves your site while processing payment. While generally a better experience for the end user, there are additional costs and PCI compliance responsibilities you accept when using these methods.
Getting donors to set up recurring monthly payments provides a steadier and generally larger donation revenue stream. Not every payment processor supports them. Some processors have discounted packages that exclude that functionality. If recurring support is something you require, be sure to research the processor options available with regard to this feature. You also need to check that the popular payment methods in your area are supported (for example, Amex and MasterCard are not supported by some payment processors).
There are a number of different service charge models employed by different payment processors. You will be able to compare and shop better if you know the average number and amount of transactions you process. You may be able to get a better deal if you consolidate payment processing with a single provider. For example, including a PoS (Point of Sale) terminal already used and potentially dealing with a credit union or bank that handles your checks may result in significant savings.
Tip
If you are just moving into electronic payment processing, be clear about your needs for accepting payment at the door of events. You may need a PoS terminal if there is no Internet connectivity.
Development and fundraising staff will be pleased to know that CiviCRM supports pledges of future gifts. When soliciting CRM requirements from staff, make sure to determine how they view their prospect funnel and what their needs are for segmenting contacts into different groups. They will probably have the most sophisticated needs in these areas in your organization, and may have techniques that can be deployed successfully for volunteer recruitment and event marketing.
Larger and older organizations are more likely to have direct mail and telemarketing campaigns. Gather information on the data export and import requirements for their systems and external providers.
A membership can be defined as time-defined access to organization benefits. In traditional member-based organizations, a contact demonstrates support for the organization and alliance with the organization through membership, and will generally receive benefits and services as a result of that relationship. However, the CiviCRM membership model can also be used in organizations that sell subscriptions or other service-type offerings where the "member" receives access for a defined period of time.
Existing membership and subscription forms should be used when developing your statement of requirements. Ask if there are any changes desired in the information collected on the form. These fields, some of which will be custom-made, will make up the profile used on the CiviMember page. They generally list all available types, their costs and benefits, and their terms (who can sign up, how long they last, and so on.). Pay particular attention to benefits that are to be automatically provided, including access to special areas of the website, free newsletters, discounts for events, premiums such as calendars or mugs to be delivered, and so on. Also note when special functionality is available only to certain membership categories, such as a youth newsletter or more communications to Platinum members.
Some membership types may not be available for purchase, such as lifetime members earned through long service. Find out if these exist, and who would need to enter them. Also ask about special cases, such as revocation of memberships, subscription refunds, or new subscriptions.
As you review event management requirements, use signup forms from recent events to reveal the kind of data collected about participants and options required, such as breakout session selections and food preferences. Try to get forms for several events. If events are supposed to be the "same", are there variations in the information collected on the form? Are they at different locations or times? Event templates can create similar events, but aren't worthwhile if there are too many variations.
More generally, are some events paid, and if so, can people pay at the door, by check, or online? Are ticket prices for different events the same? Complex price systems that are used repeatedly can be set up as easy to reuse price sets.
Many logistical requirements with an impact on CiviEvent won't be found on signup forms. For example, how speakers at the event are registered and whether provisions are required to give special guests free passes. What are the procedures to be followed at the door? Do people have to have a printed receipt or a mailed ticket in order to get it, or just be on a list of registrants? Are nametags provided?
Are blast e-mails used to invite registrations? Do your registrants often come to more than one event? If so, do you need to pre-populate the registration form used as a landing page for people's click-throughs with their name and other data?
Do you need to provide a way for registrants to contact each other before, during or after the event? Is it important to protect their e-mails while providing this access? Should only names and organizations be shared? Is it okay if non-participants see the personal information being shared among participants?
Other more complex requirements may include setting up collaboration spaces in Drupal or Joomla! for registrants to an event.
Does your organization provide grants or disbursements to individuals or organizations? Examples could be a grant for first and last month's rent to help a homeless person get stable housing, fellowships for artists, or program grants to organizations working in an environmental policy. The CiviGrant component helps organizations like yours by recording when applications are received, the decision to approve or turn down the application, when payments are made, and whether follow-up reports on the grant have been received.
You'll need to know what information is tracked about your grants. The fields in the application form are the best starting place; they are supplemented by internal forms, such as fields to record reviewers' ratings.
Although the CiviGrant component was not designed for tracking your organization's applications for grants, some CiviCRM users have found it can be used for this purpose with only a minor tweaking of field names. If your organization needs to track its grant applications, review the typical fields that are tracked, starting with application closing dates. Some may need to be supported through custom fields. If your needs extend beyond the structures provided in CiviGrant, consider using the CiviCase tools for this purpose.
CiviCRM uses the term "activity" to indicate any communication that transpires with constituents or other actions related to your interaction with the contact. CiviCRM automatically records a number of activities, including donations received, registrations for events, memberships purchased, and e-mails sent. You can also use it to record interactions such as meetings, phone calls, and e-mails sent from your normal e-mail client. While the full use of activities may add some administrative burden, the benefits are significant as you will be creating a history of interactions with a contact that can be consulted later. Being able to pull up details of a call taken a few months ago by a different staff person can help quickly resolve an issue rather than forcing it to be addressed from scratch.
Are there other kinds of activities you would like to record about your constituents beyond the types preconfigured in the system? For example, will you use Activities to track mail correspondence, or speeches given by legislators on topics of concern to your organization, media stories published by particular journalists or outlets, or create some integration with Twitter to record tweets including hash tags of interest?
Determine which activities and custom activities are to be tracked, and also the custom fields needed to record things such as a hardcopy correspondence file number, URLs to a speech, or fields recording story details.
CiviCRM activities record single specific actions or interactions such as a meeting, phone call or e-mail. Cases pull together multiple activities dealing with the same issue or concern, and allow them to be managed as a unit. Cases are very useful when it takes multiple steps over different days or months, perhaps involving multiple people, to resolve the problem or finish the work.
Many organizations need to manage cases of clients or constituents. These cases may involve requests for a legislator to attend a speaking engagement, assisting a homeless constituent to find housing, or providing a client with treatment referrals of various sorts (mental health, addiction recovery, emergency income assistance, job placement, and so on).
The requirements for a case management system are much more complex than just supporting the activities involved the cases. You'll want to determine:
- The different types of cases your organization handles
- The kinds of custom activities each type requires besides standard ones like opening cases and changing their status
- The workflows for different case types in terms of various kinds of activities (for example, intake, screening, referral, follow-up, and so on) that may occur at pre-defined or ad hoc times
- What statuses are used to track your cases
- What roles are involved in each kind of case activity
- What custom data is required for different activities
- What resources such as career counseling services available in your area are needed for different case types
- What relationships that clients may have with individuals or organizations external to your organization need to be trackable in the system, such as with their physician, social worker, or parole officer
- What terms such as client names need to be redacted during reporting
- What permissions are granted to individuals in different roles to view and edit information about their own cases or all cases
Roles and permissions, also referred to as access control lists (ACL), determine who gets to do what in your system. They are critical for data integrity, confidentiality, and privacy. Privileges to do things, or permissions, are not granted directly to individual users. Instead, permissions to do things are granted to or revoked from roles (for example, staff or volunteer coordinators), and users are assigned roles
CiviCRM running under Drupal has a rich model for controlling the functionality exposed to users in different roles, as well as read, update, and delete permissions on contacts. These permissions can be configured for sets of fields and sets of contacts. Unfortunately, limitations in the current stable version of Joomla do not support the same level of access control available in Drupal. There are often ways to work around Joomla!'s limitations in this area in order to approximate the power and flexibility available under Drupal. However, if fine-grained permission control is important to your organization you should pay particular attention to this factor when selecting the CMS to use with CiviCRM. Joomla! v1.6 will include improved access control and current expectations are that CiviCRM will integrate support in CiviCRM v4.0.
In order to create appropriate roles, groups of users that have permission to do specific things in CiviCRM need to be identified; for example, you may want to limit the ability to edit financial information to bookkeeping staff, and to view financial information to the other staff. Volunteer organizers may need to do things like add Activities, while education program staff may need the ability to add new events. Remember that individuals can belong to more than one group and will be granted all of the permissions that are available to any of their groups. General guidelines in this area are as follows:
- Give names to roles that capture a user's job function with respect to CiviCRM. For example, name it as "Event coordinators" rather than "Jake and Sandra" or "Can edit event info".
- Don't multiply the number of groups unnecessarily since it makes it harder to administer. For example, use a single "Staff" role rather than all eight titles on your organization chart if everyone is getting the same permissions.
- Use permissions to protect the privacy of personal information according to your privacy policy. Make sure your privacy policy reflects the permissions available to different users. For example, don't give "view" permission on any contact information to general users if your privacy policy says personal information will not be shared.
- Protect your data from being modified by users who might make inadvertent mistakes or malicious deletions and changes.
Integration between CiviCRM and Drupal or Joomla! involves people and content.
Not all contacts in CiviCRM need to have user accounts in the CMS used to power your website. For example, your CRM may include all voters in a jurisdiction and your website may not provide extra functionality requiring logins except to the site administrators. In many cases, however, actions in CiviCRM such as buying a membership will lead to login access and extra permissions in your CMS, such as gaining access to members-only pages of content or discussion forums.
Try to identify groups of contacts that have different permissions. These contacts will need to have user accounts in your CMS and be members of groups that are assigned different roles.
You should anticipate possible content crossover between your CMS and CiviCRM. The most common case is sending newsletters with CiviMail containing teasers of articles in your CMS with links driving people to the full articles on your site. There have been some attempts to standardize this process so that the newsletters can be rendered automatically using a CiviCRM Smarty template or a Drupal Content Template implementation. While manual cutting and pasting is the best approach for the moment, you may want to think about opportunities to take advantage of information in your CRM, such as constituent interests, by linking it with data in your CMS, like content tagged pertaining to their interests.
CRM systems are good at managing contacts and relationships. CMSes are good at managing content. In a few cases the strengths of CMS content management need to be applied to CRM contacts. For example, members of visual arts, music, or video artist organizations may need to have rich media associated with those contacts as well as have all of their dues and grant application transactions tracked. In these cases the CRM contacts will need CMS user accounts and those accounts will have CMS profiles with rich media associated with them.
The growing number of Drupal modules and Joomla extensions that integrate with CiviCRM, particularly those that expose CiviCRM data to the CMS, provide increasing opportunities to develop cost effective custom websites based on contact and relationship data. For example, an activist organization may want to display a mash up of contact information, such as their photos, quotes on a topic, or a map, in which case the information is all coming from the CRM and the functionality driving it is coming from the CMS. In-house or external consultant resources will be able to assist in gathering your custom CRM requirements in these areas.
While most of your integration work will be between CiviCRM and your CMS, it's not uncommon to have other third party integration needs as well. We've mentioned that some organizations may need higher-end e-mail services to improve deliverability and avoid the effort involved in dealing with e-mail blacklists.
Another common third party application used with CiviCRM is various forms of single sign-on authentication. These allow a single username and password to be used on a variety of systems and sometimes allow logging in on one of the systems to result in the user becoming logged in to all of them. These may be large legacy systems in some organizations or small online e-learning systems like Moodle in others. Identifying which applications need single sign-on will drive the selection of a single sign-on implementation such as LDAP.
Significant complexities result when more than one system makes CRUD (create, read, update, delete) operations on the same dataset. Two-way data integration of contact information and various secondary transaction datasets is not to be undertaken lightly. Standardized APIs and plugins are becoming more readily available for both Drupal and Joomla!, though you should fully define your specifications and determine cost as this level of integration can quickly become costly.
CiviCRM is a heavy application in terms of CPU and RAM resources. It is fairly light in terms of disk space and bandwidth requirements in comparison to media heavy sites.
You should expect need to upgrade the memory on the server currently hosting your Drupal or Joomla! site when you add CiviCRM. The web server processes, typically Apache, will be larger as they are used to execute CiviCRM's codebase. As the processes take longer to run and complete, more processes are needed to support the same number of sessions.
A small CiviCRM implementation with a moderate number of users should be able to run in a single virtual private server. This includes serving the pages via Apache, running the database, and processing inbound and outbound mail. Shared hosting accounts are not adequate, though some implementations with less than 500 contacts have managed with them.
If you have significant volumes of e-mails, consider off-loading that functionality to another service such as the outbound CiviSMTP service from UAS or an EMS provider like SendGrid. This can make a big difference in the server load.
Increases in load from more concurrent users can be handled by shifting to a dedicated server, moving the database instance to a different server, changing the frontend to a cluster of web servers, and upgrading the database server. Adding a fail-over slave database server can assist in improving performance as well, as reads can be made against the slave while writes are sent to the master. Scenarios with heavy report processing are likely to benefit significantly from this topology.
As the number of contacts in the database goes from thousands to hundreds of thousands, CiviCRM's MySQL database instance will require significantly greater resources in terms of CPU and RAM. Moving it to a different VPS or server than the web server is advisable.
Cloud computing technologies and techniques are becoming more pervasive in commercial web hosting and in-house hosting. It's becoming quite easy and common to run CiviCRM on a virtual machine image that can be reconfigured easily and quickly to reboot within minutes with a different number of processor cores and different memory allocations. This can be particularly cost effective when your organization faces large changes in usage, for example, during an election campaign.
The Payment Card Industry Data Security Standard also recognizes that moving mail services and database services off a web server is a good idea for security as well as performance.