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.
New Features in Version 2
Handling multiple contacts and contact types
Instead of processing a single contact per form submission, you can now have as many contacts on the form as you like, and they don't all have to be individuals. A simple use for this would be to allow a person to fill out their own information and their employer's on the same form.
Working with multi-valued core and custom fields
Each contact on your form can now have multiple addresses, phone numbers, websites & emails. You can also share addresses between contacts. And multi-valued custom fields are supported as well.
If you're using the new CiviCampaign component, you can now specify a campaign for activities and events.
Since you can enter multiple contacts per form, why not create relationships between them at the same time? You can specify the relationship type in advance, or expose it to the form for users to select.
Opening and updating cases
You can now create webforms that open a case, or add an activity to an existing case.
Handling event registration
You can register multiple contacts for multiple events on a single webform. They can all be signed up for the same event(s), or register for different events. Sorry, collecting payments via webform is not currently possible.
Fancy RSVP Form
Often people want to sign up multiple people at once for an event. Webform integration can make this very slick -- send out a hashed link to the RSVP webform, and users will find their own contact details already pre-filled. You can use webform_conditional to allow them to say how many friends they're bringing, and then show/hide the right number of fieldsets with no page reload. And why not create the relationships between them while you're at it? You can expose the relationship types you want to the form to let them pick from, say, "friend, colleague, spouse, etc" for each person.
Also, the same form could allow people to RSVP that they are not
coming to the event (I remember hearing that feature request on another post recently), by exposing the "participant status" field to the webform, creating a new status in civicrm for non-attenders, and then configuring that field to show just the choices you want, with appropriate labels. So "Yes I'm coming" and "Sorry, can't make it" would be what the user sees, and it would go into CiviCRM as either "registered" or "non-attender" status.
While you're at it, redirect those non-attenders to a contribution page after they submit the form, so they can still support your cause even though they're not coming in person!
Team Sign Up
You could make a form that lets the user enter an organization-type contact for their team, and specify sub-type on the form, i.e. football, lacrosse, hockey. They could then enter all the players' names, and the form submission would automatically create relationships between player and team, and the teammates with each other. It could also add them to a group so they get your email announcements, and tag them as current players.
Say your organization provides services, and tracks them using CiviCase. And say cases are typically opened or updated when a person requests a service. Enter Webform CiviCRM...
Create your service request form with the usual name and address fields, then configure your case/activity options: Choose the appropriate case type, and set the status to "ongoing". Choose an activity type like "service request."
When the user fills out the form, a new case will be created, and the service request activity will be added to the case, containing whatever details they specified. If a case of that type is already open for that person, then the activity will just be added to the existing case.
Even More Usage Ideas...
If you've been using this module already, I hope you'll add to this list in the comments: