Multiple event dates (Pro)

An event that runs more than once - a workshop repeated over three evenings, a guided tour on four Saturdays - needs more than the single Event Date the free plugin stores. With LocalForm Pro active, the Event Details panel in a form's Settings tab gains a More dates section: add as many dates as you need, each with its own start time, optional end time, and an optional label.

Adding dates

1. Edit a form and open the Settings tab.
2. In the Event Details card, fill in Event Date and Event Time as usual - that stays the first date of the event.
3. Under More dates, click Add date for each further date and fill in:
   • Date - required; a row without one is dropped when you save.
   • Start time and End time - optional. An end time is only kept when there's a start time and it is later than it.
   • Label - optional; a short name for the session ("Evening session", "Dutch-language tour").
4. Remove a row with the × button.
5. Save the form.

Dates are sorted chronologically and de-duplicated on save, so the order you add them in doesn't matter. A form can hold up to 50 dates.

A date that runs over several days

A two-day course held on 1 September and again on the 4th is one registration, not two dates to choose between. Click + Add a day under a date and give the further day its own start and end time - it inherits the times already on the date, since a course held twice is usually held at the same hour twice. The Event Date has its own The Event Date also runs on list at the top of the panel, for the common case where it is the first date that spans several days.

A date can carry up to 20 further days. They are sorted with the date itself, and if you type a day that falls before it, that day becomes the date: a session is anchored on the first day it is actually held, which is what the schedule sorts on and what the listing links to.

The difference between the two is worth being deliberate about:

	Further dates (Add date)	Further days (+ Add a day)
What it is	The same event, run again	The same run, continued
In the question	One option each - people pick between them	One option for all of them
Places	Counted per date	Counted once for the session
Attendance list	A sheet each	One sheet for the session
Calendar file	An entry each	An entry for every day

So: three evenings people choose between are three dates; a course spread over two evenings that people sign up to once is one date with two days.

A multi-day date reads as all of its days joined by +:

1 September 2026, 19:00–21:30 + 4 September 2026, 19:00–21:30 - Autumn course

That whole string is the answer stored on a submission, so adding a day to a date that already has registrations changes what they would have picked - the same caveat as changing a date's day or time, and for the same reason. Add the days before you open registrations if you can.

Asking which date(s) they attend

Tick Ask which date(s) they attend and the form gets a question listing every date - the Event Date first, then the extra dates:

• Question - the wording shown to visitors. Leave it blank for "Which date will you attend?" (or "Which dates …" for a multiple answer).
• Answer - One date only renders a single-choice (radio) question; One or more dates renders a checkbox question.
• Required - whether a visitor must pick a date to submit.

The question is added as a normal question card, placed at the top of the form the first time it appears. You can drag it wherever you like afterwards and it stays put - but its wording, type, options and required flag are owned by the Event Details panel, so those controls on the card are read-only. Add or remove a date, and the question's answer options follow on the next save.

Untick the setting and the question is removed from the form again.

Where the dates show up

• On the form page - the event facts band inside the form shows the first date followed by a +2 dates count - counted in days, so a date running over two of them counts for two (the first extra date leads when no single Event Date is set). The dates themselves are listed by the attendance question, so the band doesn't repeat them.
• In responses - the answer is stored like any other choice question: a column in the submissions table, in every export, and a per-date count in the Responses summary, so you can see how many people are coming on each date. There is also an attendance list, one sheet per date - see below.
• In the webhook payload - the answer travels under the question's field name, and the full schedule is added as an event_dates array:

{
	"event_date": "2026-09-01",
	"event_time": "19:00",
	"event_dates": [
		{ "date": "2026-09-01", "start_time": "19:00", "end_time": "", "label": "", "days": [], "capacity": 30, "places_taken": 12, "places_left": 18 },
		{
			"date": "2026-09-08",
			"start_time": "19:00",
			"end_time": "21:30",
			"label": "Evening session",
			"days": [{ "date": "2026-09-11", "start_time": "19:00", "end_time": "21:30" }],
			"capacity": 30,
			"places_taken": 30,
			"places_left": 0
		}
	],
	"fields": { "event_dates": ["1 September 2026, 19:00"] }
}

Places per date

Thirty seats in the room on each of three evenings is not thirty across all three, and Maximum registrations can only say the second. Tick Limit places per date and each date gets a number of its own:

• Places on the Event Date - the first date, the one on the Event Details panel above.
• Places on each row under More dates.

A date that runs over several days has one number of places covering all of them: it is one registration, so it is one seat.

Leave a date empty for no limit of its own. Whatever you set here sits on top of Maximum registrations, which still caps the event as a whole - a form capped at 50 never takes a 51st registration, however many places its dates have between them.

Places are only counted on a form that asks which date(s) they attend: without that question no registration says which evening it is for, so there is nothing to attribute to one. The number beside each box is what that date has taken so far.

Where the form is set to show how many places are left, each date says what is left on it as well - "8 September 2026, 19:00 - 3 places left". Where it is not, neither do they: one answer for the whole form rather than a date counting down beside a form that chose not to.

What a full date does

• On the form, it is greyed out and marked full rather than removed - somebody who came for the Tuesday needs to see that the Tuesday has gone, not wonder whether they misremembered it.
• On the server, it is refused again, so a stale page or a hand-made request cannot register for it. The visitor is told the date filled up and asked to pick another.
• The form itself stays open while any date has room. It closes as fully booked only once every date is full - and only if every date has a limit, since one date with no limit of its own means the event can always take one more person.

With a waiting list on, the two divide the work: this decides whether the event is full, the waiting list decides what happens once it is. Once every date is full nothing is greyed out any more, so somebody joining the list can still say which date they were hoping for.

Situation	What is counted
Someone picked two dates	A place on each.
A booking for four, with group registration counting people	Four places on the date it chose.
Someone on the waiting list	Nothing - they do not hold a place until you give them one.
A date you renamed	Everything already registered for it. A date is recognised by its day and time, so rewording "Evening session" does not empty it.
Someone booked on a date that runs over two days	One place, not two. The days of a session are not separate seats.
Webhook-only mode	Nothing, because no response is stored to count - the same blind spot the form's own maximum has.

Places also travel with the schedule in the webhook payload: each entry of event_dates carries capacity, places_taken and places_left (counted after the registration being delivered, so 0 means that was the last seat).

Attendance list

Once a form asks which date(s) people attend, the Responses screen offers Attendance list, one sheet per date next to Export. It writes a spreadsheet with a sheet per session - the people signed up for that date, and an empty Checked in column to tick as they arrive.

Situation	What the list does
Someone picked two dates	They appear on both sheets.
A date nobody picked yet	Still gets its own (empty) sheet, so the workbook matches the schedule.
A registration made before a date was renamed	Keeps a sheet under the answer it was given, rather than being dropped or filed under the wrong session.
A registration with no date answered	Collected on a final No date chosen sheet.
A date that runs over several days	One sheet, holding the people signed up to that session - they are the same people on each of its days. Its tab is named after the first day plus a +1 day count, because a spreadsheet tab has only 31 characters and every day spelled out would be cut off mid-date.

The list honours the date range and search box on the Responses screen, the same way the ordinary export does.

In the calendar file and in search results

Both follow the schedule rather than only its first date:

• The calendar file attached to a registrant's confirmation carries one entry per date, each with its own start and end and its label in the title, instead of the single entry core writes. A date that runs over several days contributes an entry for each of them: half a two-day course in the calendar is the day the registrant doesn't turn up for. Add a date later and the entries already in somebody's calendar stay where they are - each is identified by its own day and time.
• The form's page describes every date as an event of its own for search engines, linking to the form with that date already chosen, and marks a date with no places left as sold out. A date running over several days ends on the last of them, so a search result doesn't advertise a two-day course as a one-day one.

Notes

• Answer options are written in the site's date format, and that formatted text is what gets stored on a submission. Changing the site's date format (Settings → General) therefore doesn't rewrite answers already collected; the event_dates array in the webhook payload always carries the machine-readable dates.
• Duplicating a form copies its dates and the question setup along with it.
• Without Limit places per date, capacity is not tracked per date at all: Maximum registrations counts the whole form, and one popular session can use up the lot.