If you've recently upgraded to CiviCRM 4.1, you'll need to upgrade your webform_civicrm as well. Versions 2.3 and below are not fully compatible with Civi 4.1. Version 2.4 is, and will be released in the next couple of days, especially if I get a few comments on this post from people who have sucessfully tested it! The latest -dev is stable and working, so please feel free to download it and try it out on your 4.1 site!

Note: webform_civicrm 2.4 is not backwards-compatible with older versions of CiviCRM, and should only be used with 4.1.x

One of my favorite features in CiviCRM 4.1 is the improved support for custom tokens via hooks. It's really opened up the possibilities for building some great functionality and new workflows in CiviCRM. If you already know what tokens and hooks are, skip down to see some cool examples.

This time of year I would normally be entring data from hundreds of sheets of paper, struggling to read people's sloppy handwriting and feeling like I was a slave to our database. But instead, I'm viewing reports on phone calls, pledges and donations, generating reminders and thank-yous -- with no data entry required!

I've just released a new version of the CiviCRM Webform Integration module for Drupal 6 and 7.
This module provides a flexible and powerful way to create forms linked to the CiviCRM database. Version 2 of the module is built for CiviCRM 3.4/4.0, and can create and update contacts, group subscriptions, tags, relationships, cases, activities, event participants, and custom data.
New in 2.3:

I've just released the stable 2.0 version of the Drupal Webform CiviCRM Integration module and wanted to share some of the cool new things you can do with it.

Version 1, which I wrote earlier this year, was basically built for a single purpose: you could have a user fill out a webform, and their contact record (name, address, email, etc.) would be created/updated and an activity of the form submission would be logged. That alone is pretty darn useful, but suggestions from users, the advent of API v3, and a commission from the core team got me setting sights higher for the next release.

Like many others who have no doubt gone before me, I found myself spending a large chunk of time this week finding and merging duplicate contacts. Civi's deduping UI has gotten a lot better lately, and I love having the ability to go through it more quickly than before. But deduping is only as good as the queries it runs, and of course prevention is better than cleanup.

Here are some observations of how all those dupes in my DB got created:

Fans of Webform CiviCRM Integration will be happy to hear that version 2 is now available for testing. And if you're not already a fan of that module, this might put you over the edge.

With version 1, you were able to:

• Create/update a single Individual via webform
• Log a simple activity for that contact when the form was submitted
• Allow the user to opt-in to groups
• Tag contacts

Version 2 take that to a whole new level, giving you the ability to:

The Drupal core contact module provides a no-frills way for users to email you via a simple webform. If you like that module, but would also like those form submissions to be recorded in CiviCRM, then this no-frills extension is for you.

The webform module is a great way to collect info from your contacts, perfect for things like application forms, surveys, contact forms, feedback forms, etc. The hard part is getting those form submissions to actually link to your CiviCRM contacts... until now.

A few months ago as our organization was just starting to use CiviCRM, Dave Greenberg recommended that we look at CiviCase as a solution for our admissions team to keep track of prospective students. As a collection of activities associated with a client, CiviCase looked like a great way to record our interactions with potential students as we made initial contact, followed up, received communication from them, sent more info, and then accepted their applications. From a DB point of view, yes, it is a nearly perfect way to store that information. But from a UI point of view, we had a long way to go before our admissions team would be able to painlessly get the data in, work with and update it once it was there, and then be able to get it back out in the form of reports. Here's what we did to make that happen (and more!):