Compared to CiviCRM Profiles
CiviCRM has the ability to embed a "profile" (set of CRM fields) on a page (i.e. user/register) or as a standalone form. This works well in some cases, and not others. Compared to profiles, webforms:
Conversely, webform_civicrm forms have a few limitations:
Compared to CiviCRM Contribution Pages
Contribution Pages offer:
These are not directly supported by Webforms, but there are some workarounds.
Keep in mind the referenced contribution page must have these features (widget, PCP, etc.) enabled to work properly.
Working with Existing Contacts
Enabling the "Existing Contact" field gives you many options for how a contact can be autofilled or selected:
Some fields contain a CiviCRM contact id, for example activity assignee, case manager, and certain custom fields. This module treats those fields as pointing to a webform contact, which allows you to take advantage of all of the above "Existing Contact" features, but makes setting up the contact reference slightly roundabout. Here are the steps, for example, to assign every activity created by a webform to Bob Smith:
Like any contact-reference field, current employer can be configured in a number of ways to suit your needs. Here is a sample configuration that allows users to add/update their employer via an autocomplete:
Note: The this will only work if the current contact has permission to view organisation contacts; or if the permissions on the "Existing Contact" field for Contact 2 have been ignored by un-checking 'Enforce Permissions' (use with caution).
A few variations
Creating new Contacts
The module can also be used to generate new Contact records from information provided in the webform.
Creating Drupal users at the same time can be achieved using the CiviCRM Entity module, with rules integration, as described in this blog post:
Autofilling Forms from URL Arguments
This module can autofill and update contacts and activities based on ids supplied in the url. Supported arguments:
Notes about url arguments:
Generating URL Arguments
There are several ways to generate a link to a webform with contact ids in the url:
CiviMail provides tokens for adding cid and cs to any link. Your constituents will thank you for not making them fill out their name, address, etc when you already know it. To send out personalized links to your form in CiviMail, simply copy and paste the url provided under "Additional Options" on the CiviCRM tab of your webform into your CiviMail message.
Views tokens make it easy to link to a webform and supply a cid. This works great as a view/edit combo for privledged users, or as a contact form (example). To do so, create a view of CiviCRM contacts, add a contact_id field (hidden from display) and pick a field to rewrite as a link. The link url would be something like "/myform?cid1=[id]".
From Other Webforms
This module provides hidden fields for cid and cs which you can use as tokens, allowing you to send a hashed link from a webform-generated email, or redirect an anonymous user to another webform or CiviCRM page upon submission. An example use for this would be that upon completion of your webform, the contact will receive an email containing a hashed link directing them back to the form in case they wish to update their information. Another example would be to redirect them to a CiviCRM contribution page, pre-filled with their contact information.
Webform Submitting tokens
This module provides 3 tokens that can be used after submitting the webform , these 3 tokens are :
Where ? can be replaced with the number of contact, activity or case that the webform is going to create or update starting from 1 (where 1 refers to the first contact/activity or case , 2 refers to the second contact/activity or case ..etc) . Each of these tokens will show a link to the specified contact , activity or case.
E.g ) If your webform is configured to create two contacts and two cases , then you can use all or any of the following tokens inside your post webform submission message :
And if the result of submitting this webform was creating a contact with 100 and other one with ID = 101 as well as two cases with ID = 50 and ID=51 then the following message should appear after submitting the form :
Here is how it work in action :
1) configuring the confirmation message :
2) submitting the webform :
Any CiviCRM field with options (whether it's a simple yes/no select, your upcoming events, or countries of the world) can be fully customized:
The downside of customizable options is that they are static: if you update an option list in CiviCRM, the corresponding webform field will not reflect those changes unless you click the edit button as described above and enable the new options.
Live Options: Alternately, you can set a field to use "Live Options." This will load the option list from the CiviCRM database every time the form is viewed. Live option lists cannot be customized, but will ensure your form element stays up-to-date. Because of the slight performance impact, this setting is best used only with options that have some possibility of changing in the future.
Groups and Tags
This module allows you to tag contacts and add them to groups when they submit the webform. Hold down CTRL or SHIFT to select more than one. Groups/tags you choose on the CiviCRM tab will always be added to the contact, and you can also choose -user select- to make a webform element. See "option lists" above.
Using a Limited Amount of Groups: Once you have selected -user select- for the groups in the CiviCRM section of the webform admin section, save and return to the 'components' tab (where all the webform fields are listed). Find your groups field and edit it from the component list. If you change the list from Live to Static, you can then select which of your groups will appear as an option to the user.
Opt-In Confirmation: In the "additional options" section is a checkbox to enable confirmation emails when contacts are added to public mailing lists. It is recommended that you leave that option enabled in most situations. You may configure the text of the confirmation message using CiviCRM Automated Messages.
This module can handle any custom fields you have created for contacts, addresses, event participants, cases, relationships, or activities. Note that not every type of widget exists in the webform module, or behaves exactly the same as its CiviCRM counterpart, for example the "advanced multiselect" becomes a simple "multiselect," "rich text area" becomes a plain text area, and a "datetime" field is split into sepearte "date" and "time" Webform fields. There are some good add-on modules to give more options, e.g. Chosen, Webform Autocomplete, and Webform Html Textarea."
Event registration via webform is extremely flexible; any number of contacts can be registered for any number of events on a single form. If your form has multiple contacts on it, you may choose to register them each separately for different events, or all together for the same event(s). If you choose to register them together, CiviCRM will show contact 1 as having registered the others.
To allow participants to return to the form and update their registration info later, see the section on sending hashed links from a webform email.
With payment integration, events can be paid for online or offline via webforms (see notes below on supported payment processors). Note that CiviCRM pricesets are not supported and fees should instead be allocated using the "event fee" field provided by this module.
Editing webform submissions
Editing previous webform submissions will cause the corresponding information in CiviCRM to be updated. This is useful if you want to allow users to edit event bookings, for example. But care should be taken if editing 'old' submissions for a webform: for example if you correct a typing error in an old address submission then the entire submission will be written to the contact record again; as if it had just been submitted.
There is currently a feature request to make the 'Editing webform submissions updates CiviCRM' functionality configurable (enabled/disabled) per webform.
This module can create, renew, or cancel one or more memberships for one or more contacts. Paid memberships can be handled via payment integration (see notes below on supported payment processors). Note that CiviCRM pricesets are not supported and the default "minimum" fee will be charged for each membership term.
Using Webforms, you can accept online payments for contributions, events and memberships or any combination of these on a single form.
Unsupported payment processors
Most major payment processors compatible with CiviCRM should also work with this module. If you are having trouble with the processor of your choice you can search for an open issue on the drupal.org issue tracker or file a new one if you don't find one already open. Note that software development is not free and you will likely need to contribute your own time or funding toward a fix.
Accepting payments through a webform
When creating a contribution, event or membership webform that includes payments, first set up a dedicated contribution page for the sole purpose of embedding it on one or more webforms. Most of the contribution page settings will be ignored by the webform. Only the following need to be configured:
State/Province and Country Fields
This module gives similar functionality as core CiviCRM profiles for the state field of an address:
None of the above applies to custom fields. Custom fields of type state/province will be a non-dynamic dropdown list of all "Available states and provinces" you have enabled in CiviCRM's localization settings. This is the same behavior as on CiviCRM profiles.
About the "Not You" Message
This feature exists to help prevent a major CRM headache: If users view your form while logged-in as someone else, or they click to your form by following someone else's personalized link (i.e. from a forwarded email), they will see that person's details on the form. Not given any alternative, they are likely to manually clear those fields and type their own information, which would cause the existing contact to be updated with a different person's details, throwing your contact data into confusion.
When enabled, users will see a message instructing them to "click here" if they are not the intended contact. The link will take them to an anonymous version of the form. Make sure unknown users have access to the webform if using this feature. Note that the user will stay logged-in so while webform_civicrm will treat them as as an "unknown" user, they will still have all their usual privledges. (this is the same behavior as if you uncheck the "Autofill Contact 1 with Current User" option on the CiviCRM form settings)
Cloning a Contact
This is particularly useful to avoid re-doing all your webform component customizations for each contact on the form.
Retrofitting an Existing Webform
You can start recording CiviCRM contacts even for an existing webform. This falls into two scenarios:
Will Contacts, Activities, etc. be Created Retroactively if I Enable CiviCRM Processing on an Existing Form?
No. That would require some sort of batch update script, which is not part of this module.
Will Webform Submissions be Updated if a Contact is Modified in CiviCRM?
No. Think of each submission record as a snapshot of what was actually entered on the form. It doesn't necessarily reflect current CRM data.
Changing a Webform Component Type
The Webform module has no method for changing a field from one type to another (i.e. turning a textfield into a select, hidden, etc.). This module fixes that shortcoming for CiviCRM components, since the default widget is not always how you want a field to be presented. On the webform tab, click to edit any CiviCRM component and you will have the option to switch widgets. Note that there are some common sense reasons why some fields would not work well if you changed their type - for example, changing a select into a textfield is probably a bad idea because the user would be likely to enter a value that is not a valid option.
Anatomy of a Form Key (for geeks only)
This module uses form keys to identify CiviCRM fields. The convenation for these keys contains 6 pieces, connected by underscores. They are:
So this field is for the postal code of the first address of the second contact on the form.
Note that for consistency, all form keys are treated as if everything might be multi-valued. So even though a contact can only have one first_name, the form key for contact 1's first name is still "civicrm_1_contact_1_contact_first_name" which tells us that this is a field for the first contact on the form, and the first (and only) set of contact fields for them.