Hashed links from webform to civiforms - a solution for collection Organisation details for Event registrations and more

Published
2012-07-01 16:31
Written by

 

After more meanderings around the Universe of Webform_civicrm (Creator: Coleman) I started thinking that I should find a way to use it to collect more complex information about Organisations and Relationships which might be required as part of an event or membership registration.

The prompt for this particular meandering was that currently Event Registration does not provide any in-built options to collect information about an Organisation that the registrant might represent, beyond the Organisation Name (currently employer) and Job Title.

I was expecting to need to code this in to civi for an event that allowed for a multiple person registration and therefore anything we did to collect Organisation info for Person 1 would not be required for subsequent persons.

However, having seen Coleman referring to a 'hashed link', it finally dawned on me (oh alright with just a bit of help by big C) that since webform_civicrm could provide both a hidden Contact ID field and a hidden checksum, that we might be able to attach these in the weform redirect field and have an Anonymous user shifted to a pre-filled Event form where they would do the rest of the registration.

Well it all works superbly.

 

RECIPE

One CiviEvent or Contribution Page (that you put in the oven earlier)

One webform_civicrm form with at least Contact 1 (individual) and Contact 2 (organisation)

Go to the Webform Component for Contact 1 called Generate Checksum

Grab the snippet of code from there, which for above scenario would be cid1=%value[civicrm_1_contact_1_fieldset_fieldset][civicrm_1_contact_1_contact_contact_id]&cs=%value[civicrm_1_contact_1_fieldset_fieldset][civicrm_1_contact_1_contact_cs]

Grab the path for the Event/Contribution form

Go to the Webform "Form Settings'" tab and find the Redirection Location field

Paste in the path for the Event/Contribution then add on with a '&' the snippet from the checksum making sure you replace the cid1 with just cid

Run a few tests incognito.

Enjoy the pleasure of seeing the Webform create the contact person and the organisation with all the fields you can think of, and then smile as you get passed over to the civiform where you will see your anonymous users details prefilled and the 'Current Employer' field, if you chose to have it showing here, filled with the Organisation created via the above.

Dim the lights, light the candles, bring in the cake, celebrate.

 

(Note to self ... well, and coleman, lobo and others)

What would be awesome would be to be able to use the 'register for event' options in the Webform-Civicrm and then just pass the user over to CiviEvent to make the payment. The barrier to this is of course civi doesn't allow a contact to update their Participant data - ie if we use Event registration option in Webform then when we get to civi we get the "oops you appear to have already registered for the event"

Any thoughts on how to either sidestep this when coming from webform - or even to sidestep whenever a contact uses a checksum to get to the Event form. The latter would mean emails could be sent out to contacts so that they can then update their details - not sure if that option via checksum has been discussed and put in the 'kind-of-hard' basket.

 

Comments

Another barrier is that CiviEvent is somewhat inflexible in what sorts of registrations it will allow. Webform_CiviCRM can register any number of people for any number of events (and it doesn't have to be the same events for each person) while also collecting (as you noted) a whole lot of other information at the same time.

But CiviEvent will not allow you to register others for an event without registering yourself (i.e. it won't allow parents to sign their kids up for a camp or school event). It also won't allow a variable number of registrations per person.

So that combined with the fact that CiviEvent can't update registrations (Webform_CiviCRM can, by the way) the "hand off" from webform to Civi would be sort of a non-starter at this point.

Note that there is an event cart in 4.1 (Adam Wight?)  & some work in 4.2 around registering children without parents (Parvez) - I haven't explored either of these so am not sure to what extent they address the problems you describe.

Hey - yes, this work was done in 4.2 and we have a live client using it in 4.1. The amendments in civicrm allow participant registration without needing to provide an email address - which was (is) the limitation in events registration. Again, not sure if this deals with your issues but may help in some way!

Anonymous (not verified)
2012-12-22 - 08:10

I was excited to read this post, and try this out. It addresses a use case that I first encountered two years ago.

However, I have used Civi and Drupal very little until this month, and I was disappointed when I followed your instructions and Drupal/Webform said "That is an invalid URL." I looked around, and eventually found someone explaining that tokens (and therefore the URL you wrote about) only work for internal URLs that are written relative to the Drupal root. This is probably obvious to you, and stumped me for 30 minutes.

I'm glad it's working now, and appreciate your explanation that got me most of the way, and the coding that makes it possible.

~ Patrick

I am glad i wrote it down too - 6 months later and really needed these instructions