Publishing and resolving conflicts

What this covers

The step between building an event and it going live, and what happens to bookings that already exist on those dates. This is the most involved part of the Events module, and the part worth reading before you need it. Needs the manage-events permission.

Publishing

Open the event and choose Publish. Tabledoo works out the real dates, then checks each one for bookings that already exist on the tables the event wants.

• No clashes — the event publishes. Tables are blocked, and guests can book.
• Clashes — publishing stops with "Resolve all conflicts before this event can go live." The event stays a draft.

This is a hard gate, not a warning. Nothing goes live, and no table is blocked, while a single clash is unresolved. The event page tells you where you stand: "3 conflict(s) must be resolved before publishing", and later "All conflicts resolved — ready to publish."

It exists so that publishing an event can never quietly cancel somebody's anniversary dinner.

Resolving a clash

Each clash is listed with the guest, their table and their party size. You choose one of three things.

Include

The party joins the event. What that means depends on the seating mode, and the difference matters:

• Seated event — nothing changes for them. They keep their table, inside the event.
• Communal event — they become part of the shared headcount. Their places are added to the event's sold count and their original table booking is released, since there is no separate table any more.

Communal Include now messages the guest automatically. Seated stays silent — correctly, nothing about their evening changed. Communal queues them the same confirmation email a guest who booked the event directly gets, telling them their booking is now part of the event. A personal call on top is still worth it for a big regular or a special occasion — an email is not the same as being told in person.

If the party is outside the event's own min/max pax you will see "Party size outside event range". You can still include them — you are acknowledging the exception deliberately.

Change table

Move them off the event's tables and let them have their normal evening. Tabledoo offers only tables that genuinely work for that booking at that time. If there are none, it says so — "No alternative tables available — include or cancel instead."

This is usually the kindest option, and the first one to try.

Cancel

Cancel their booking. You are asked for a reason, and the reason is shown to the guest — Tabledoo suggests "Table reserved for a private event". The guest is sent the normal cancellation message.

Write the reason as something a guest should read. It is not an internal note.

A sensible order to work through them

1. Change table where you can — the guest keeps their evening and you keep your event.
2. Include where the party would genuinely enjoy the event — communal now emails them automatically; call as well for a big regular or a special occasion.
3. Cancel last, and phone anyone worth phoning before the automatic message goes out.

For a big regular or a special occasion, a call first costs a minute and saves a review.

Dates released later resolve themselves — mostly

The gate above applies when you publish. Dates released automatically weeks later have nobody to ask, so Tabledoo resolves what it safely can on its own: a seated clash is always included automatically (nothing changes for the guest, so there is nothing to ask permission for). A communal clash is different — the newly released date stays off-live, exactly as if you had just published it yourself, until you open it and resolve the conflict the same way you would at publish time. See Recurrence and event dates.

After publishing

• The tables are blocked — they show as Held for event on Live View and as a band on the Timeline.
• The public page goes live. Copy the Public link from the event page and share it.
• Each date shows Ready and starts taking bookings.