Places in Cameo where you need to identify an event now offer a list of events to choose from. For example, when you create a list for emailing event attendees, you need to say which event(s) it applies to. (Previously you had to enter one or more event instance numbers provided in the event definition).

Note that:

Background

Cameo’s events manage simple, free, one-off functions, through to multiple performances over several days in different venues, with allocated seating and paid-for tickets at different prices depending where you sit and your status. Events can also cover appointments and equipment loan or hire.

In general, therefore, you can’t just name the event when checking people in for an event, or emailing participants. You must also give the specific date, time and location of the event.

Each performance or occurrence has a unique, identifying number, called an instance of the event. Until now, you had to enter the number(s) for the events of interest into a box for things like lists, booking forms etc.

Event selection

Cameo now replaces those with selectors to choose the event from. This avoids the need to keep switching back-and-forth to look up numbers.

This applies in:

  • Lists with event attendees as their source (Fig 1).
  • Event booking forms, when identifying the event(s) they should offer to book for (Fig 2: 2). (You can still use the instance query parameter explicitly in a URL. Existing URLs continue working).
  • Attendance forms (which allows people to check-in for an online event), when identifying the event to check people in for.
  • News builder event blocks.

Just the name is sufficient to identify simple, one-off events. Therefore you only need to select the minimum to uniquely identify an event, the name in this case. The selector displays the date, time and venue for confirmation.

In the more complex cases, unique identification of an event needs all of name, date and time, and venue. For example, you could even have multiple performances at the same date and time but in different places. In this case you would have to select all three to identify the specific event.

Fig 1: for lists with source event attendees, instead of a text box where you enter event numbers, you now choose the event(s) the list should apply to with an event selector.
Fig 2: (1) events which a booking form should apply to are identified by its default query parameters (when not given in the form’s URL); (2) though still identified by event number, you use the same selector as above to determine what these are; (3) similarly, use a selector to choose tags when identifying events by tag (see below).

Event tags

An event number (formerly instance) narrows down which performance or occurrence of an event you mean. In contrast, an event tag does the opposite. Tags broadens event selection. They allows events to be grouped together under a single name of your choice, identified en-masse by that name.

For example, you could give a tag film-shows for all your film shows. This would let you:

  • have a booking form which will work for all your film shows (by selecting the events by tag name)
  • email everyone who has booked for or attended a film show

without identifying each such event individually.

For the booking form, tag names are now also selectable from a menu. You no longer have to remember a name, and risk typos when entering it.

Lists for tags of event

For email, there is also a new list source event tag attendees. This works just like event attendees. However, it identifies the events concerned by tag. Anyone booking for new events assigned that tag in the future would automatically be included in the list as well.

The summary of events in the Events section now also includes a column for tag (Fig 3: 2). You can filter based on tag in the heading of the new column.

Fig 3: (1) event number replaces instance, (2) tags shown in events summary, along with filter by tag