CiviCRM 2.3: Introducing New CiviEvent Features

As mentioned previously, we’re introducing quite a few new CiviEvent features in CiviCRM 2.3. Most of them are still undergoing our internal CiviCRM QA cycle, but do check them out at our CiviCRM 2.3 sandbox if you’re interested (there is still time for some minor fixes to accommodate your use-cases!). Waitlisting CiviCRM 2.3 introduces the concept of wait lists, where participants who registered after a given event was full are placed. These participants are informed before their initial registration that the event is full, and if they continue their registration process, they are put on a waitlist. Once the event gets some free spaces (because some other participations expire, or participants cancel their participation, or are removed by an admin, or the event gets more spaces…), a cronjob-based script makes sure that the participants from the top of the waitlist (first-registered-first) are moved to pending state. Participant Approval Another new feature is the participant approval – any event can be configured in a way that participants can he hand-approved by an admin before they’re considered registered for that event. Participant Confirmation To make the above concepts workable, CiviCRM 2.3 introduces a two-stage registration process. Participants can partially register for an event and then finish their registration in a separate step (for example when they’re hand-approved or when they’re moved from the waitlist because of free event spaces). Participant Expiration Again, to make the two-step registration manageable, a new per-event setting was introduced. If a participant is put in a pending state (because they chose to pay later, or got in from a waitlist, or were approved), a time limit when they have to finish their registration (or get cancelled) can be set. Event Templates To make new event creation simpler, the concept of event templates was introduced. One an event template is constructed (in the Administer CiviCRM area), new events (and, actually, new event templates) can be based on it. This should make the creation of recursive (or otherwise similar) events a breeze. Separate Profiles for Additional Participants To enhance the features for group registration, separate profiles can now be set for the main and for the additional participants. To keep backward compatibility, all upgrades from pre-2.3 will assume that additional participants should use the same profiles as the main participant, but this can be quickly adjusted on a per-event basis. Relevant issues You can see the full list of CiviEvent issues targeting CiviCRM 2.3 in our issue tracker.

Comments

The interface has been improved and is now more user friendly.

Instead of having a wizard with most of the steps that are irrelevant to your specific need, you have tabs allowing you to fill only what you need in the order you want to fill it.

X+

P.S. On that topic, the (disabled) could be changed by greying the disabled tab, that'd be nicer and save space.

Still learning and evaluating CiviCRM, events are a key part of our needs, we have used Regonline for years. These enhancements ring some bells. Is there a concept of a "private event" that would appear only for members of a certain group? The cycle would be to email members of the group, and when they login, they would see the event, but others would not. I intuitively feel CiviCRM would support this, but I'm not familiar enough yet to understand how.

I think this covers most of our use cases. One additional case (for which we have added custom code) is to have undisclosed registration - or exclusive invitation. The challenge is that we have events available for anonymous users but may want to invite a select few to register. We have code to prevent the registration button from appearing for that type of event and we send out an email invitation with a "private URL" ie. the unpublished registration link. (please talk with Altaf for more details on how we implemented)

Templates are great - anything to optimize the event creation workflow.

One big management challenge we have is that we often get partial, unpaid registrations using google checkout / paypal or if the user is Pay Later. they will signup again later so we have 2 records, one paid, one not paid. It would be great if we had some dedupe logic to close out the pending event/contribution record. Even if it was just a tag on the pending records to indicate that a similar transaction exists and we can go through and clean it up. right now its a painful, manual process. keep in mind we use price sets for our fundraisers and offer lots of options to contribute so matching can get a bit tricky.

A few more wish list items:
Send email if pending to let the event coordinator know there is a problem.
An internal event name in addition to the published event title to manage many events (with the same name!)
Event cancellation by user (might require authentication such as email verification)
Event / contribution adjustment
Configurable reminders for participant expiration
Recurring events
Improved matching of event and contribution record (ie.when you add/delete an event record, you are offered to create a contribution record also ability to find quickly see the contribution record with an event
Better integration with Drupal event module

One final question - contribution pages can be used like events - why do they need to be different modules? Is there an opportunity to consolidate?

I hope this is helpful - thanks for listening to users!

S.