Skip to content

Recurring events

When reserving an event, use the Repeat control on the Basic info step to book a whole series in a single submission. You can adjust it later on the When step too: select Change in the line above the calendar. Admins and Managers can do this, just like single bookings.

It starts at Doesn't repeat. Every day, Every week and Every month cover the common cases, with − N times + beside them for how many. Custom… opens the full builder for anything else.

The repeat comes before the date. Set it first and the calendar can tell you how a run starting on each date would go; until it's set, there's nothing for the dates to be checked against. If you're not repeating anything, nothing changes — pick your date as you always have.

The repeat rule lets you choose:

  • How often — daily, weekly, or monthly, with an "every N" interval (for example, every 2 weeks).
  • Weekly — which days of the week. This defaults to your start date's weekday until you pick your own days.
  • Monthly — a day of the month, or a weekday like "the second Tuesday".
  • When it ends — on a date, or after a number of occurrences (the default is after 12). A series always has an end — it can't repeat forever, and very long series are refused.

The submit button changes to Reserve series.

A run often happens at more than one time. A show with evening performances and a Saturday matinee is one production, not two bookings — so a series can hold several schedules, each with its own days and its own clock.

Select Add another schedule under the repeat rule. Each schedule gets:

  • Starts at and Lasts — its own time of day and length. The matinees can run at 2:30pm for 150 minutes while the evenings run at 7:30pm.
  • Its own days and end — a full repeat rule, set the same way as the first.
  • A name you choose — "Matinees", "Schools performances". Leave it blank and Venvy names it from the rule and time, like "Weekly at 2:30pm". The name is what you'll see everywhere afterwards, so it's worth setting.

A booking can hold up to six schedules. A second schedule starts with no days picked and says so — it's for a different time from the first, so copying the first schedule's days would only manufacture a clash.

Two schedules can't produce an event at the same instant in the same room, and Venvy says which two if they would. Two schedules on the same day at different times are fine — that's the whole point.

Once a series holds more than one schedule, no single sentence describes it: "every Wednesday until 24 October" is true of one schedule and false of the run. So the form lists every occurrence it will create, in date order, each one labeled with the schedule that produced it. Check the list before you reserve — it's the only complete statement of what you're about to book.

If the list shows something wrong with a schedule you added earlier — the wrong room, date, time or repeat rule — select the pencil (Edit) on that schedule's card. It reopens that schedule in the same step that built it, with its own dates and times loaded. Make the change, then continue back to the list.

Editing one schedule leaves every other one alone: they keep their order, their names and their dates. The schedule you were working on before is kept as you left it, and comes back when you return. Nothing is booked until you press Reserve.

Because the repeat is set first, the calendar can do something it could not before: each date shows how a run starting there would go, not whether that one day is free.

Each date says who would pay for starting there: nobody, another event, or you.

  • A room is free every date — at least one room can take every date, so nothing moves and nothing is lost. Other rooms may still bump an event; the room list shows each one.
  • Bumps another event — the run books in full, but a lower-priority event is moved out of the room to make space for it. Its manager is told when you reserve.
  • Some dates taken — the run books on some of its dates and loses the rest.
  • Every date taken — a run starting here books nothing at all.

The key above the calendar names the states in play and re-words itself as you change the repeat, so it always says what it is currently describing. It covers the month you are looking at, not every date loaded behind it.

A date that is free itself can still say "some dates taken" — that's the point. A Tuesday with nothing on it is a poor place to start if the fourth week is taken, and the old calendar had no way to tell you.

Tapping a date doesn't change what the other dates say. Each date is judged as the start of its own run, so the color that made you tap is the run you get. Earlier, if you hadn't chosen your own weekdays, tapping a date quietly rewrote the repeat to that date's weekday and re-colored the whole calendar — so the answer you acted on could disappear in the act of taking it, in both directions: a date shown as clear could turn out to cost you occurrences, and a date shown as costly could have been fine.

Days your repeat can't start on are shown as unavailable. If you've chosen your own weekdays — Tuesdays and Fridays, say — a Wednesday isn't a possible first date, so it's drawn greyed out like a past day, can't be tapped, and isn't counted in the key. Before, those days looked available and simply moved your date somewhere else when tapped.

When Repeat is on, the room list checks each room against every date the series lands on — not just the first one. So a room never reads as free if a later date has a clash. With more than one schedule, that means every schedule's dates together: a room that's free for your evenings but taken for one matinee doesn't read as Free.

Each room shows what booking it there would cost, never as a fraction — a count like "6 of 12" makes a consequence look like a coverage report, so the room says only the consequence itself:

  • Free — clear on every date.
  • Bumps on 7 — the room books in full on every date, but on 7 of them a lower-priority event is moved out to make space. A short line under the room names each event this displaces and the dates, for example "A-Team Practice · Sep 21, Oct 19", and who is notified.
  • You move on 8 — on 8 dates, an equal-or-higher-priority event already holds the room and can't be moved, so your own event would take a different room on just those dates.
  • 2 dates taken — the room can't be booked on 2 of its dates at all.
  • Not free — every date is taken.

This lets you pick a better room, or adjust the times or rule, before you commit.

If the time, duration, or repeat rule changes, or you add, change or remove a schedule, the summaries recompute for the new set of dates.

You don't have to get every date perfectly clear before booking. When you reserve a series that clashes on some dates, Venvy books the dates it can and handles each contested date on its own. Before anything is booked you land on the Review step, which names your schedule and states the answer up front — for example "All 12 dates book · 7 bump another event, and on Sep 28 that event has nowhere to go." Nothing changes until you press Reserve.

Below that, every date that isn't simply free gets its own row, in date order:

  • A lower-priority event gets bumped — your event outranks it, so it's moved to another suitable room and its manager is notified. This is the same relocation that happens for single bookings, now applied per date. If that event has nowhere to go, the row says so plainly, since that's the one outcome a reassuring checkmark would misrepresent. The row also says why:
    • "Needs room for 12 people — the biggest free room, Office, seats 8." A room is free, but none is big enough.
    • "Every other room is already booked for this time." No room is free at all.
  • Your own event moves — an equal-or-higher-priority event holds the room on that date and can't be moved, but another room is free. Your event takes that free room for that date only; the other event is left untouched and no one else is notified. Venvy suggests the best free room and pre-fills it — you can pick a different room from the list, or choose Skip this date to leave that date unbooked.
  • The date is skipped — an equal-or-higher-priority event holds the room and no other room is free for your event that date, or one of your own other rooms is already booked. The date can't be booked, so it's left out. No one is notified.

A run of three or more consecutive dates with the same outcome is shown as one row rather than one per date. If every date turns out blocked, nothing is reserved and Venvy asks you to change a room or the times first.

Booking a bumped event into a smaller room (admins)

Section titled “Booking a bumped event into a smaller room (admins)”

If you're an admin and a bumped event has nowhere to go only because no free room is big enough, its row offers Override — book in room anyway. Press it to move that event into the biggest free room even though it's too small for the event's headcount. The row then reads, for example, "Will book in Office anyway — seats 8, needs 12." Press Undo to change your mind. Nothing happens until you press Reserve.

A few things to know:

  • The override only relaxes the room's size. It never puts two events in the same room at the same time. If every other room is already booked, there's nothing to override into, and the row doesn't offer it.
  • Venvy checks again when you press Reserve. If a big-enough room has come free since you looked, the event goes there instead and no override is needed.
  • The event's manager is notified of the move, the same as for any bumped event.

Venvy books the resolved dates in one step and confirms how many were reserved — for example "Series reserved — 10 dates booked" — along with any dates that were skipped. A series can therefore span different rooms on different dates (wherever "You Move" applied) and can be shorter than requested if some dates were skipped.

Each occurrence appears on the calendar as an ordinary event — colored by room and included in filters, exactly like a single booking. Because "You Move" dates can land in a different room, occurrences in one series may not all share a room.

That also means each occurrence is managed on its own: editing or deleting one occurrence changes only that date, not the rest of the series. See Editing and deleting events.

A booked run's repeat rules live under Schedule in the event itself, listed as Repeating Sets — each with its name, its time, the dates it has actually produced, and its manager (or No manager). A set that has stopped stays in the list, because the dates it made still belong to it.

Here's what you can do to a run from there. Each one asks first, tells you exactly what it will do, and only then does it — including naming any dates someone has moved by hand, because those are the changes about to be undone and usually only one person knows they exist.

Adds another repeat rule to a run that's already booked — matinees to a run of evening performances, say. It's the same builder used when reserving, plus a Starts on date for where the new rule begins — it suggests today, or the run's first night if that's still to come.

Then it asks where the new dates should meet, with the same room list you reserve from. The rooms your run's next date uses are ticked to start with; change them if the new set belongs somewhere else. Check these dates runs the same room checks a new booking gets and shows you every date before anything is booked: which are clear, which move a lower-priority booking out of the way, which step into another free room, and which can't be booked at all. It also says how many dates the rule makes and the span they cover. Nothing is added until you confirm, and the confirm button says how many dates will actually be booked. A date that can't be booked is left out, exactly as when reserving.

A new set can also have its own Managing user, which starts empty. Leave it empty and the set has no manager of its own, so its new dates get the manager of the run's latest date. Choose someone and the set's new dates are managed by them.

Useful when each set has its own instructor, say. Manager… on a set's card lets you set, change or remove who manages it.

  • Starting with — pick the first date the new manager takes over. It starts at the next date still to come. Dates before it keep their manager, and dates that have already happened never change.
  • Dates with their own manager aren't changed quietly. If a date was handed to someone else on its own — a substitute for one week — it's listed with a checkbox, unticked. It keeps its manager unless you tick it. If the set had no manager, a date counts as having its own when it isn't managed by whoever manages most of the set's dates; if no one does, every date is listed.
  • Who's told. The set's previous manager, if it had one, and the new one each get one Manager changed notice naming the set and how many dates changed. A date you tick also tells the person it's taken from.
  • Removing a set's manager changes no date and notifies nobody. Every date keeps the manager it has.

The set stays one set — nothing is split. A set that has stopped can't change its manager. To change who manages just one date, use Managing user in that date's Basics instead.

Ends a repeating set. Venvy decides which of two things that means, and tells you which before you commit:

  • If the set has already played, it ends at its last played date. Those performances happened, so the set stays on the run holding them, and anything still to come is canceled.
  • If it hasn't played yet, it's removed from the run entirely — there's nothing for it to hold.

Stopping can't be undone. Canceled dates aren't restored and their tickets aren't re-issued. If you need the run to continue later, add a new set from a future date.

Moves a set to a new time from a date you choose — "the matinees run at 3:00 from October". Dates before that keep the time they have, because those performances happened at the old time.

Starting with picks that date, and the date you pick is the first one the change applies to. Where there are dates on both sides of it, the run genuinely becomes two repeating sets: the first closes on the date before the one you picked, and a new one takes over from it at the new time. Venvy says so before committing, naming both dates. That's deliberate — one set claiming a time that's wrong about half its own dates would be misleading everywhere it appeared.

The dates themselves move; they aren't remade. Everything attached to them — tickets, approvals, anything edited by hand — stays with them.

Moving dates runs the same checks as changing an event's time. Before anything changes, you see every date whose new time is taken. A lower-priority booking in the way moves once you've seen it, and admins can choose where it goes. A date whose new time is held by an equal-or-higher-priority booking keeps its current time and goes to override approval.

If you change the set's rule and it makes dates the set didn't have, those are new bookings. Venvy asks where they should meet and checks every date, the same way Add a set does.

Changing only a set's length doesn't split it. Its dates from the one you choose run longer or shorter, and it stays one set.

Edit… on a set that hasn't had any dates yet has a Starts on date. Change it, and Review changes tells you exactly what happens before anything does:

  • A later start cancels the set's dates before the new start, and names each one. Dates on or after it are left exactly as they are.
  • An earlier start adds the days the set's rule makes between the new start and its current first date. Those are new bookings, so it asks where they should meet and checks every date, the same way Add a set does.

If the set's rule ends after a number of dates, it's changed to end on the set's last date, so the rule still matches what's booked.

A start can't be in the past — and that now means the time as well as the day, so you can't set a set to start at 9am today at 2pm this afternoon. Venvy says which it is: "Tuesday, Sep 15 has passed. Pick another date." or "9:00am today has already passed. Pick a later time or another day." And once a set has had a date, when it started is history — the start date isn't offered. To change what a running set does from now on, change its rule or time from a date instead.

Edit… a set and move its end date later to keep it going. It stays the same set, and nothing already booked changes.

The dates it adds are new bookings, so it asks where they should meet. The rooms the set's upcoming dates use are ticked to start with. Check these dates then shows every added date before anything is booked, the same way Add a set does: which are clear, which move a lower-priority booking out of the way, which step into another free room, and which can't be booked at all. A date that can't be booked is left out, and the set keeps every date it already has.

A set that has stopped can't be extended. Add a new set instead.

Moves the whole run into different rooms. Use it when the question is about the run rather than about one night — a production moving to a bigger stage for the rest of its dates, say.

It asks one thing: where the run should meet. The event's name, its type, who manages each of its sets, its schedules, its dates and its times all stay exactly as they are — they're shown at the top of the page so you can check them, and you change them by editing the event itself. Nothing is created: this moves the run you already have, it doesn't book a second one.

Only the dates still to come. A date that has already played keeps the rooms it was held in — there's no room decision left to make about it. The page says how many dates it will reach and over what span before you pick anything. If those dates don't all meet in the same rooms today, it says so, and rebooking puts every one of them in the rooms you choose.

Every room is priced against the whole run, not against one night — "Free on all 17 dates", "Free on 15 of 17". If you add a second room, Venvy tells you the cost before you tick it, because two rooms are rarely free on all the same dates:

Adding this room moves 15 of 17 dates — the other 2 keep the rooms they have now

Those dates aren't canceled and they don't drop out of the run. They stay where they are, in the rooms they already hold. Before anything saves you get the full list by name, with the reason each date can't take the new rooms, and nothing is written until you confirm.

A room another event is using can still be picked. If the run outranks what's there, that booking is relocated — the room says so before you choose it ("They move on 9 dates"), and the confirmation names whose booking moves and where it lands.

Dates the room can't take are asked about one at a time. Some dates will be held by something the run doesn't outrank. Each is listed with its own choice: keep the rooms it has, or move it to a room that's genuinely free on that date — which is rarely the same list two dates running. Keeping what it has is the default and a perfectly good answer; nothing is canceled either way, and only the dates you actually change are written.

Rooms held together still have to be free. Adding a second room with Add another room means the run only takes dates where both are free, so it can shorten what moves. The list tells you the cost before you tick it — "Adding this room moves 15 of 17 dates — the other 2 keep the rooms they have now".

Taking a date from an equal-or-higher-priority booking

Section titled “Taking a date from an equal-or-higher-priority booking”

Some dates are held by something the run doesn't outrank. Those can be taken — one date at a time, and never the whole run at once. A run of twelve dates contested on three of them is three separate questions, and answering two of them yes is an ordinary outcome.

Each contested date offers Take it alongside the ordinary choices, and says whose booking it would move and where that booking would land. Where there's nowhere free for it, the date says that too — taking it then leaves somebody without a room, which is a different decision and is presented as one.

You can also send that booking somewhere other than the suggestion. Venvy suggests the best free room and that's a perfectly good answer; if you know the building better, pick another from the list.

Sometimes nothing is free only because the displaced booking is down as more people than any free room seats. Where that's the cause — and only then — Venvy says which booking's head-count is in the way and offers to correct it there and then, naming whose booking you'd be changing. If the room a correction would unlock is the very room this date is leaving, and no other room would fit either, Venvy says the two would trade places; if another room would also fit, it names every room a correction opens up instead. Correcting it re-checks where that booking could go straight away.

An Admin who can override takes the date immediately, and the whole rebook saves in one go, exactly like any other.

Anyone else asks, and this is the part worth reading twice: nothing happens until an Admin decides — not the contested dates, and not the rest of the run either. Every date keeps the room it has until the whole rebook can be applied at once. A rebook that looked like it saved and changed nothing would be the worst possible reading of that rule, so the page says so before you submit.

If you'd rather not wait, move the other dates now and ask for the contested ones separately. That's offered on the same screen — rebook without them, then come back and ask.

The run itself shows what's outstanding: which dates were asked about, who asked, and a Withdraw the request button if it was you. Withdrawing changes nothing, because nothing was ever held.

If it was you who asked, the request also appears under Override requests awaiting approval in the Pending Items panel on Home — the run's title when your calendar would show it to you, or just Your request when it wouldn't — alongside its own Withdraw request button.

You can still rebook the run while a request is pending. It's worth knowing what that costs: the request is re-checked against the calendar as it stands when it's decided, so if you've moved things in the meantime, deciding it may then refuse — and the Admin is told why.

If a date arrives before anyone decides it, it simply drops out. That isn't a refusal, and the run's record says so.

Per-date requests appear in the Approvals queue beside single-date ones, labelled with the run and how many dates it covers. The Admin answers each date separately — granting some and declining others is normal — and can send any displaced booking to a different room as they go. "Grant all" is there as a shortcut, and it records the same per-date answers as pressing Grant on each.

Deciding is what applies the save. The whole rebook goes in at that moment, contested dates and uncontested ones together, re-checked against the calendar as it stands then. If something has moved in the meantime, the save is refused whole and nothing changes.

Afterwards the run shows each date's own answer — granted, declined, or never decided in time. Anyone whose booking was moved is told once, naming every date it was moved on and where each one landed; a date left without a room is told apart from one that merely moved, and shows up as needing a room.