In Part 1 of this article we explored the major benefits and broad concepts of RedHen CRM. In this article, we will take a detailed look at RedHen's current feature set - as demonstrated in our sample RedHen installation profile.
In this RedHen CRM demonstration, we will show how the framework could be leveraged to build an association management system (AMS) supporting a fictional organization: The National Association of Pet Shelters.
In this example, we have created two different types (or in Drupal speak "entity bundles") of individual contact records - one for shelter staff and another for volunteers, each with its own unique set of fields. Similarly, we have created two different types of organization records - one for the shelters themselves and another for foundations that support the work of these organizations. We can then leverage RedHen to show the connections between these contact and organization records, as well as to manage both individual and organizational memberships within our fictional association.
Working with Contacts
Configuring Contact Entity Bundles
RedHen CRM defines a custom entity type for "Contacts." As mentioned above, RedHen CRM allows site administrators to create their own "contact bundles" - each with its own unique sets of fields:
Below is a listing of the fields that have been added to our demonstration CRM's "volunteer" contact bundle:
The "RedHen Contact Email" field is a new field type defined by RedHen CRM to provide additional options for managing the unique email communication preferences of your RedHen contacts. The "Availability" field provides an example of how we can extend contact records to include additional, customized field data about our contacts.
Filtering Contacts
Once we've configured our content entity bundles, we can view and search our contacts across various fields and properties:
Notice that when we change our "contact type" filter (or, in Drupal speak, when we filter on "contact entity bundle"), RedHen CRM's contact listing automatically pulls in the fields available as filter options for the selected bundle:
Working with Individual Contact Entities
The default contact entity display:
Editing fields and properties on a contact entity (In this case, a staff contact entity):
Connecting Content Entities with Drupal User Accounts
Optionally, you can choose to associate contact entities with Drupal user accounts on your site. You can either choose to connect the contact entity with an existing user account:
Or, you can create a new Drupal user account for the contact entity from within the RedHen interface:
Within the next month, we will be extending this feature to allow Drupal users to edit their own content information via this linkage. But for now, this feature is primarily leveraged for managing access control and Drupal user roles via our membership management tools, which we describe shortly.
Working with Organizations
Organizations work similarly to Contacts. RedHen defines an entity type for organizations - which can be extended by a site administrator as custom organization entity bundles.
Connecting Contacts and Organizations
RedHen CRM leverages the Relation module to allow for different types of relationships (or connections in RedHen CRM speak) between contacts - as well as between contacts and organizations.
As with all the other entity types/bundles that are part of RedHen CRM, these relationships are fieldable:
This means that you can add fields to your relationships to track metadata about the connections between RedHen entities.
Managing Primary Contacts for Your Organizations
When managing connections between contacts and organizations, site administrators can also determine the primary contact for an organization entity. See the "Primary Contact" link on the right-hand side of the screenshot below:
The primary contact is a dynamic property for organization entities, and has been exposed to Views and Rules.
Managing Memberships
Our clients' reoccurring need for a flexible and customizable membership management solution was one of our primary motivations in developing RedHen. Selling Drupal user roles with Drupal Commerce, or managing the expirations of Drupal user roles with contributed modules such as Role Expire is simply not a robust enough solution for large membership organizations with complex business rules around membership-based services.
Individual vs. Organizational Memberships
With this in mind, RedHen CRM allows you to create different types of memberships, which can be applied to both content entities organization entities. These membership types are, of course, entity bundles, so again - they are fieldable.
Assigning Drupal User Roles Via Memberships
As mentioned above, Drupal user accounts can be associated with RedHen contacts. Once these connections are made, the assignment of an active membership can be leveraged to provide a user account with a Drupal user role.
When a RedHen membership that is associated with a Drupal user role is assigned to a RedHen Organization - this role is applied to all Drupal user accounts associated with contacts related to that RedHen organization.
Let me repeat this point, because it is truly one of the most unique features of RedHen CRM:
With RedHen CRM, you can manage Drupal user roles via organizational memberships.
Role-based Membership Benefits
It goes without saying that Drupal's role-based permission and access control system is one of its great strengths. Combining the Drupal user role framework with CRM functionality represents on of the most important value propositions of RedHen CRM and, more generally speaking, native Drupal CRM tools.
Leveraging RedHen CRM with Drupal Commerce, you could use these membership management tools to provide discounts on e-commerce transactions. Leveraging a wide variety of contributed access control modules, could you could also build premium content libraries. The "Association Management Solution" (AMS) opportunities are endless.
Capturing Notes on Contacts and Organizations
Notes can be added to both contact and organization entities. As an entity bundle, notes can be extended with fields.
In the case of our RedHen Demo CRM, we have extended the notes bundle with a taxonomy reference field for the "type" of note that is being recorded. When viewing note history, these notes can then be filtered by this type taxonomy.
Engagement Scoring
In the notes screenshot above, you'll also notice a dropdown option for Engagement Score.
Engagement scoring (often referred to as "engagement analytics" or "engagement metrics") is a relatively new concept in measuring the interactions of web site visitors. Web analytics packages such as Google Analytics generally focus on measuring quantitative analytics - or the number of page visits and clicks. Engagement scoring focuses on measuring the quality of these interactions by weighting the value of different types of interactions between site visitors and your website. For example, sharing an article from your website to a social network might be worth "5 engagement points", commenting on a blog post might be worth "10 points."
The RedHen Engagement module provides an API and framework for tracking this type of engagement. The module also integrates with the "RedHen Notes" module, so that offline interactions with RedHen Contacts can also be tracked and scored. To learn more about engagement scoring in RedHen, check out this blog post.
Tracking Event Registrations
RedHen CRM integrates closely with the Entity Registrations module - which our ThinkShout geeks also maintain. As shown in the screenshot below, the Entity Registrations module allows you to manage event registrations as entities.
When enabled, the RedHen Registration module adds an additional tab to the contact entity screen called "Registrations." There, both authenticated and anonymous event registrations will be listed for each contact, based upon a matching email address.
Note: In the future, we plan to extend this module such that new registrations associated with email addresses not found in RedHen CRM will trigger the creation of new contact entities.
RedHen Organizations as "Groups"
The RedHen Organization Groups module allows you to groupify organization entity bundles.
This module provides functionality similar to Organic Groups. A groupified organization can have node content associated with it. Optionally, this content can be made private, and therefore only viewable to Drupal user accounts associated with RedHen contact entities which are in turn associated with a specific RedHen organization entity.
In the screenshot below, you can see how a node can be added to a groupified RedHen organization:
Then, when looking at a RedHen organization entity, you can see all associated group content:
So, why not just use Organic Groups?
The description above begs the question: Why not just use OG? In developing this feature, we considered leveraging Organic Groups. However, the relationships between Drupal user records, contacts and organizations were too complex to cleanly build this feature on top of both RedHen and Organic Groups. That said, much of the architecture of this module is based upon design patterns from Organic Groups.
What's Next?
ThinkShout will be launching our first client sites on RedHen CRM this summer. We are currently working towards a stable 1.0 release of RedHen - while simultaneously exploring new features and tools.
We are very interested in continuing to explore:
- Deeper integration with Drupal Commerce.
- CRM data visualization - most notably geolocation and mapping of constituent data, as well as Google Charts visualization of engagement scoring data.
- Bulk import tools, as well as Migrate 2.x integration.
- Apache Solr integration.
- The development of better HTML5 and responsive themes for RedHen CRM interfaces.
We hope that the community will continue to work with us to make RedHen CRM a leading association management solution. We'll see you in the issue queues and at a Drupal Camp near you!
Comments
This vs. CRM_Core
Looks really, really cool! With the Drupal entity system, it seems the time has come for a Drupal-based CRM structure.
My only question is this: are you familiar with CRM_Core, and how do you see RedHen as being different from it? Would it make sense to combine projects at any point? I began a fairly ambitious CRM project using CRM_Core, not knowing about RedHen, and am pretty happy with it, but then again this looks great too. I think it makes sense to use the best system for the job, but after seeing this I'm not sure what that would be for me.
Great question!
First off, I want to give a big shout out to the other two native CRM projects under active development: CRM Core and the Party module. If you want to learn more about the overall work going on in this area, consider joining the CRM Drupal Users Group. In my opinion, the effort benefits from diversity of approaches.
As for the specific differences between RedHen CRM and CRM Core, admittedly I haven't talked with folks at Trellon about CRM Core since DrupalCon Denver, but my general take is that what we're doing with RedHen is a bit more "developer-centric." For example, RedHen CRM doesn't require Views or Features, opting instead to rely on EntityFieldQuery and custom APIs. We provide Views support obviously, and you can override all of our interfaces with your own Views if you would like. But you don't need Views. The reason for this is that, in our opinion, customizing RedHen to meet your own specific requirements is more reliable when working against core APIs rather than exportables.
Along the same lines, I think that our feature set is a bit more prescriptive than CRM Core. As mentioned in the article above, we've put a lot of thought into "association management" features - like our membership management sub-module. There is a lot of business logic in this module around managing Drupal user roles based upon both individual and organizational memberships. We want to provide a very tight user experience out-of-the-box with RedHen CRM, while at the same time providing developers with a solid framework upon which to develop their own custom implementations.
Anyway, that's just my take on the differences. Obviously I'm bias. But again, we really value the fact that there are a handful of CRM options out there in D7.
Contact types and grouping
Hi,
I've been playing with redhencrm for a while now - great job!
I just have a quick quesiton regarding a more specific use case. Frequently if you have contact types like "volunteers" "supporters" "donors" or similar - they are not very static groups. Many people are supporters at first, then become donors and finally may even volunteer (or the other way roung). But currently I don't really see a concept that allows you to turn a volunteer into a donor record for an example.
The only workaround I can think of is to use relationship and declare specific records as "old" while mapping them to the new one. But that's not really pretty :-)
How would you solve that (or which little detail did I overlook).
Thanks in advance & Cheers
Us taxonomy
Hi Florian,
Great question. There are a couple of reasons that we've provided a framework for creating different contact bundles for different types of contacts:
This approach is analogous to using different content types on your site. That said, you have touched on a compromise that such an approach requires - just as you can't change the content type of an existing node, you can't change the contact bundle of an existing RedHen contact entity.
In your use case, I would consider using a single contact bundle, and then using a combination of taxonomy and conditional fields to manage small variations in the field-level data that is collected for different types of contacts. Make sense?
We're excited to have you continue to explore RedHen CRM. Please keep the questions coming!
Cheers, Sean Larkin
I think Florian has hit on
I think Florian has hit on not just a compromise but an Achilles heel of the approach. The relationship between an organization and its contacts is always going to be fluid over time--with the only variable between organizations being how quickly or slowly the relationships change. And it's more than just Active and Inactive membership. And it's precisely because organizations want to change the user access and change the relationships available to that person when a contact moves from being a volunteer to being a staff member or vice versa that this is an issue. For a small organization with low turnover, disassociating the old contact type from the Drupal user, archiving that old contact and creating a new contact of the right type might work. But for more fluid organizations or organizations with multiple overlapping contact engagements (some contacts are just members, some are donors, but some are member-donors, and you want the last to have access to the content and relationships of both the member and donor groups--say, so that the member donors have access to the membership roster--not visible to pure donors--AND get invited to the annual donor appreciation party--something non-donor members don't get invited to) this won't work.
Sean's onto something
Ha, I saw this comment come in and I was going to suggest the same thing as Sean. For "fluid" contact types-- that is, contacts that might morph from one type into another-- use taxonomy to divide them. The use the Conditional Fields module to show/hide other groups of fields specific to, say, "volunteers" or "donors". As a slightly more complex example, you could use the Field Collection module to collect specific types of notes on, say, volunteer activity. But those field collections could be hidden (using Conditional Fields) until you selected "Volunteer" from your taxonomy field.
Taxonomy - but field bundles?
Ok, I was thinking about this separation through taxonomy as well, but I didn't know about the conditional field stuff.
I'm only familiar with the idea of attaching field bundles on "contact types" in a more flexible way - like for an example party CRM does it. It uses the concept of hats that can be placed on any contact record and this way flexible fields can be assembled onto one contact type.
But for a simple approach taxonomy will be fine, thanks. Will play a little more :-)
Cheers
Field collections will work too
I haven't played with Party in the last month, but I believe that parties work similarly to field collections. The same approach described above would work with field collections too: add a taxonomy reference field that triggers conditional fields to display a field collection.
While a bit off topic from your original post, I think that this is a good place to point out that one of the key differences between the way that RedHen is architected and the way that the Party module is designed is that we've decided to compromise a bit of the "point and click" configuration options that ship with RedHen, in favor of a more codified approach. Our reason for doing so is that we're releasing a large number of RedHen features that require complex business logic.
For example, look at the way that we're handling access control based upon organizational memberships:
This complex business logic is somewhat hard to even describe - but it's an absolute requirement for an advanced "association management system" (or AMS). I don't mean to take anything away from the architectural decisions made in Party, but in our opinion, RedHen is a better platform for developing robust, bulletproof CRM/AMS tools that will someday compete with enterprise solutions.
Hi Florian,
Hi Florian,
Party's method of "bundles" sounds cool, although it may be overkill for many use-cases. Hearing what you want to do, I'm confident you can do every "bundling" task with core Fields, Field Group, and Field Collection-- and then turn whole groups of fields "off" and "on" via the Conditional Fields module.
I've never accomplished this kind of task specifically for a CRM, but I have done so in other instances. Here's an example: I built a peer-review system for a client, and the original manuscripts being reviewed were a number of different document types-- scientific papers, book chapters, conference presentations, etc. Each needed somewhat unique sets of fields, but it didn't necessitate entire different node types for each one. So we used Taxonomy to determine what type of document was being uploaded, and then used Conditional Fields to enable or disable the groups of fields based on their relevance to each type of document.
Caveat: Conditional Fields is still in -dev.
Organization not showing up as an entity
When I try to replicate your example by adding an organization, I'm not sure how you're doing this.
I don't see Organization as an entity when I do an Add Content. At the RedHen Dashboard if I click Add Organization I get a message that i must first add an Organization Type. Likewise, Organization doesn't show up in Structure as an entity or as taxonomy vocabulary. If I click on organization type creation page link (ttps://devcrm.east.multco.us/admin/structure/redhen/org_type) I get an Access Denied page. I've checked Modules and all applicable modules are installed and enabled. I'm site administrator and I have privileges to all the objects.
What am I missing? Thanks ....
Do you mind posting to the issue queue on D.O.?
Hi Kevin,
Thanks for reaching out. Do you mind posting questions like this to our issue queue at: http://drupal.org/project/redhen/issues? That way you can engage a wider audience of developers and site builders using RedHen.
Without more specifics, such as the versions of each module that you've enabed, it's difficult to help you track down this issue. I can say that Organization entities are of their own entity "type." They are not nodes or taxonomy terms. I'm not sure why you are getting that access denied error. Again, without more info it's hard to say.
You might be interested in trying out the RedHen CRM Demo install profile: http://drupal.org/project/redhen_demo.
Good luck, and we look forward to working with you via the queues!
Cheers, Sean
Donations
I recently had a client that wanted a simple donation form on their site. The form needed to collect contact information and create/update a contact record and obviously take payment on the donation. We ended up using CiviCRM, b/c they wanted to do a lot with their contact data, but it felt like it was overkill.
You mention Drupal Commerce a lot. Can RedHen integrate with Drupal Commerce to take donations and collect contact data at the same time? Any plans for something like this? Can I help build this? (I'm a developer and my company may have a client coming up that this would be perfect for).
Donations - any update on this?
Is there any progress towards implementing a way to get donations into Redhen? This would prevent us from moving some clients from CiviCRM since that is a core feature that non-profits use. Otherwise, I love the idea of having the CRM in Drupal and having more flexibility.
I am not sure what ThinkShout
I am not sure what ThinkShout is planning or doing, but I recently implemented one site that had donations (with only Drupal Commerce, no CiviCRM), and another site that has fairly large and robust RedHen installation.
My sense from having done both of these— although admittedly not together in one site— is that using Drupal Commerce with its Donation components should work quite well. The Commerce Cart can be streamlined to make donations easier, and the Custom Line Item Types module allows for the site to collect donation-specific metadata.
Then, look at Drupal Commerce's Rules integration. By default, Commerce has several rules that, upon checkout completion, check for an existing user (by email address) and either (1) creates a new user or (2) "assigns" the order to an existing user. You could pretty easily extend (or replace) these rules so that they also create RedHen Contacts and/or "assign" the order to existing RedHen Contacts. I imagine you could do the same with RedHen Organizations instead.
You could also use Views (together with the Google Chart Tools or Visualization API modules) to show stats of donations per RedHen Contact.
I hope I made sense! Let me know if you have questions.
Exactly....
Nathan's right on. We use Drupal Commerce with RedHen CRM all the time for integration CRM functionality with donations, membership management, and paid event registrations. As of right now, we use a bit of glue code to handle the logic of creating/tying Commerce transactions to RedHen contacts, but Rules can work well too for many use cases. We're in the process of trying to abstract out a lot of what we're doing to make this stuff easier on site builders. But at the same time, we find that most clients have specific workflows and use cases that require a small amount of customization. Fortunately, the APIs for Commerce and RedHen are solid, so it's very fast to build exactly what our clients need.
Assigning Contacts to specific team members
This article is great for people fairly new to the idea of Drupal and CRM, such as myself. I might have missed it, but what is the best way to assign specific contacts to someone in our organization? Through memberships? Organizations?
I am trying to make a team members experience as simple as possible, so I want to have them only see contacts assigned to them.
Again, great work.
entity reference or relation
Thanks Cam. Your best bet is probably by adding an Entity Reference field to contacts, which can contain either other contacts or perhaps Drupal users. Another option to explore is through the use of RedHen connections, E.g., you could create a contact -> contact connection of type 'owner'. Good luck!
I know this is a very late
I know this is a very late reply, but...
One thing I've done is use Organic Groups (OG). It is an alternate way of grouping instead of using RedHen Organization grouping. One possible advantage to using OG is that it comes bundles with robust field-level permissions and Views Contextual Filters. So, for instance, if a group of people (e.g. employees at a regional office) needed to "work" a certain group of RedHen Contacts, grouping both the employees' user accounts, and the RedHen Contact entities, within the same OG Group allows permissions to work nicely.
For example, if you have 5 employees and 100 contacts, all of which are grouped, say, in an OG Group called "Phoenix Office", then if one employee in Phoenix added a new RedHen Contact, all other employees in that office could view and edit that new contact. Thus they are "shared" between all of them.
Sometimes, you might want to "assign" a contact to a particular user. You could do that too-- as Lev says, via Entity Reference or something similar. It really depends on your client's needs. What I love about RedHen is that it allows any Drupal-type data relationship natively.