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.
Until now, getting your webforms to work with CiviCRM was a little like Groundhog Day. You wake up in the morning, create the usual form (First Name, Last Name, Address, City, State, Zip, Phone Number, Email, etc.). An hour later, you're done with the easy part. Now you have to write a custom PHP script to intercept those form submissions, call up the Civi APIs (go A team!), and start trying to match up field keys to API $params. It's kind of tedious, and doesn't always work the first time (was it supposed to be 'prefix_id' or 'individual_prefix' or 'individual_prefix_id'?). But a few hours and a few dozen test submissions later you've got it all working. Now you can call up the Activity API and create an activity for contacts when they submit the form. And if you really want to be nice to your users, you could use hook_form_alter on that webform and set all the default values for logged-in users so they don't have to fill it out themselves. It'll save them a little time, but getting it all working won't save you any, trust me. And that's it, you're done untill... next time you want to create a webform! Then Groundhog day starts all over again.
But thanks to the spiffy new Webform CiviCRM Integration module, all that is in the past. Now you can have all those mundane contact fields (name, address, phone, etc) created for you, and you're free to get on with the important work of actually creating your application form, feedback form, etc. When users submit the form, the submission will be automagically linked to their CiviCRM contact record, (using your default strict dedupe rule if they're anonymous, or simply their user id if they're logged in). An activity of your choice can also be created upon form submission. And of course no one likes filling out the same info over and over again, so this module auto-fills forms for logged-in users... and it goes one step farther. Send out a link to your form using the familiar {contact.contact_id}&{contact.checksum} tokens in CiviMail, and even anonymous users won't have to fill out their contact info on their form.
I told you it was spiffy.
This module brought to you by your friends at Woolman.org
Comments
Awesome can't wait to try it out!!!
Please correct me if I am wrong. But, can't one do the same by exposing the form created in CiviCRM? So, if I want people to create an individual profile, can't I set up the form in CiviCRM and expose it similar to how one can set up a registration form?
I seem to be missing something in my understanding of why Webform is even required.
Hi,
I'm not familiar with the webform module (as in never used it). Why haven't you used the profile if this is to create a simple contact, or the civicampaign petition module if this is to create a contact + activity ?
X+
The webform module is super useful for making one-off forms. You can make lots of them, and ask lots of questions in them, without junking up your Civi database with zillions of custom fields. This is not to say that Civi profiles aren't great, but you might find this module to be more suitable in some situations. Here's one example: Your organization is hiring for a job, so you create an application form on your website. You could do this with custom activity fields and profiles, but the fields you create aren't exactly re-usable, because you might ask different questions next year, so then you're just stuck with yet another custom field group in your db. A dozen hiring cycles later things are starting to get pretty cluttered. Pretty soon you have to start asking yourself if you want to start deleting those old apps to make things less crowded. Deleting perfectly good data isn't good record-keeping practice, and it's not the data that's the problem; it's the schema. Using webform eliminates those problems, and webform_civicrm lets you keep the data in civi that you want (namely an activity indicating that the form was filled out) without burdining you with all the stuff you don't want.
Creating custom fields and profiles in Civi is also pretty time consuming, because you have to do everything twice -- once to create the custom field in the first place, and then you have to do it again to add it to the profile. With this module you can create over a dozen contact fields in a single click. And thanks to the arrange_fields project, You can then drag and drop those fields just about any way you please to make your form oh so pretty with ease.
Sound good? Give it a try! I'm not claiming this module replaces any of the wonderful features already in Civi, it just compliments them, hopefully making CiviCRM more accessable to more people.
And thanks for sharing!
X+
Yup, it just got spiffier. Check out the new version with civicrm custom data support, personalized welcome messages for known contacts, a handy hidden field for CID, and a few other tweaks and improvements.
Get the new version here.
Would it be possible that you put it under a scm ? eg github ?
X+
Hi Xavier. Drupal.org is actually switching to git this week, so I'm pretty happy with the module living there unless/until the civi team decides to bundle it with the CiviCRM package.
I cloned this from git, and it appears to work, however I am not sure if your previous solution about the employer field is a solution to my question. Because I am using this webform for members only and it will be used by people who use the other database linked via the "External ID" field, is it possible to pass that number as a hidden field? Would I need to enable that in a profile somehow?
Also, I checked to have it add an activity, but wasn't able to find the activity afterwards. Though, because Webform keeps a log in it's view I am less concerned of that right now.
Thanks for any suggestions.
Passing in external_id as a hidden field would require you to somehow know that id for each contact and be able to populate that field prior to the webform submission. How exactly would you do that?
As to being able to find activities via advanced search, the latest version fixes that issue.
Cheers :)
...are a god.
Great work!
Here's a wee question, though: are the Civi fields you can pull in limited to the ones shown in the enable fields section? I REALLY want to pull through Current Employer as a hidden field so that it shows in the results (to admin). Is this do-able?
Thanks again,
RJB
In answer to your question, current employer is actually a relationship, not a field, so what you're asking is a bit beyond the scope of this module. However, you may be interested in some work I'm doing to improve the display of webform submissions. Currently when you go to /node/xxx/webform-results all you see in the "name" column is "Anonymous" for each person (unless they were logged in, in which case you'd see their username linked to their profile). I've written a little template override to change that to the civicrm display name linked to the contact record -- much more useful. Now I just need to figure out how to actually make it override. Me and my friend Google are stumped about this, so any pointers from anyone out there would be welcomed. Specifically, the question is: "how do you get one module to override another module's tpl.php file?"
For your specific need, you could achieve that by copying the file /sites/all/modules/webform/templates/webform-submission-page.tpl.php into your theme folder, and then you could put this code at the top (or wherever you want it to appear):
<?php
require_once 'api/v2/Contact.php';
$cid = $submission->civicrm['contact_id'];
$params = array( 'contact_id' => $cid );
$contact = civicrm_contact_get( $params );
print '<strong>Current Employer:</strong> '. $contact[$cid]['current_employer'];
?>
Because my module takes care of adding civicrm contact data to every webform submission object, tasks like this one become pretty easy.
Hi,
When you use the contact get api, you should explicitely list the fields you want to fetch (to avoid doing a lot of join on tables to get the country, email, phone and so on that you will never read).
The current employer is a relationship indeed, but has been denormalised as a field in the individual (aptly named current_employer for the name and organization_id for the id).
Last but not the least, as of civicrm version 3.4 , the api v2 is deprecated, and the code is
$cid = $submission->civicrm['contact_id'];
$params = array( 'contact_id' => $cid );
$contact = civicrm_api('contact','get', $params );
print '<strong>Current Employer:</strong> '. $contact.results[$cid]['current_employer'];
?>
X+
Hi X, I realized after posting that comment that specifying a return value would have been slightly more efficient, but left it open in case RJB wanted to print out other stuff as well.
And since the v3 APIs haven't actually been released yet, I gave code that will work today rather than some time in the future. But I'm super excited to use the new ones, they look fantastic. Are they ready for testing? I really should be more on top of this, but life happens...
Sooooo, in advance of API V3 (exciting!), what code would you recommend just to pull through current employer and keep it efficient? I'm thinking a mixture of what you each posted, but I'm a bit of a learner here and don't want to bodge it.
Thanks again!
RJB
But you can go with the api 2, and add one or several param reuturn_thefield_youwant.
X+
...works fine. If you want to shave a few milliseconds off your page load, use this code instead.
<?php
require_once 'api/v2/Contact.php';
$cid = $submission->civicrm['contact_id'];
$params = array( 'contact_id' => $cid, 'return_current_employer' => 1 );
$contact = civicrm_contact_get( $params );
print '<strong>Current Employer:</strong> '. $contact[$cid]['current_employer'];
?>
And be sure to download the latest version of the webform_civicrm module for the most satisfying experience :)
Being a big, dribbling eeeeeejot, I've tried adding the code you posted to a copy of webform-submission-page.tpl and putting that into my general theme folder. I've also tried putting it into the folder garland as a test - no bones either way. Am I leaving out something incredibly obvious? What should I be looking out for as a sign of success? No extra info comes through onto the results of a submitted form, as far as I can see.
Sorry to be so thoroughly useless, but - as ever - Im massively grateful for your help!
Robin
PS: I'm guessing I need to add a new hidden field in with a default value using a token... any idea what that should be?
No, you don't need to add a hidden field or anything like that. Simply copying the template into your active theme folder, adding the code I posted, and clearing your theme cache (automatically done every time you visit /admin/build/theme) will do it.
Thanks to the Great Drupal GIT Migration, this module now has its own project page where you can view and file issues and bug reports (bug-free so far!). If you like this module and would like to help it get out of "sandbox" mode, please add positive feedback to the project application and set the status to "reviewed and tested by the community" if appropriate.
UPDATE: Project application accepted, thanks for the community support!