Skip to content
English
Do you need help? Customer portal
neowit.io
  • There are no suggestions because the search field is empty.

Cancel a recurring meeting after repeated no-shows

A weekly meeting that nobody attends takes up a room every week. After enough no-shows, the meeting probably isn't real anymore — somebody set up a recurring booking and forgot. Use a workflow to count no-shows on the underlying series and cancel the whole series once the count crosses a threshold. For facilities or operations teams who want to reclaim chronically-unused rooms without manually hunting them down.

What this workflow does

  • A Booking No-Show trigger fires whenever the booking automaton releases a meeting because nobody showed up.
  • An If condition checks that the event is part of a recurring series (isRecurring and masterId present).
  • A Counter action increments a counter keyed by the series master's id.
  • A second If checks whether the counter has crossed your threshold.
  • A Cancel Booking action cancels the series master — removing every future occurrence from everyone's calendar.

Heads up — this is destructive. Cancelled meetings are gone for everyone. There's no undo from inside Neowit. Pick a high threshold (10 or 20 to start), watch a few executions, then ratchet it down once you trust the workflow.

The finished workflow on the canvas: Booking No-Show trigger → If (isRecurring + masterId) → Counter (increment) → If (count >= 20) → Cancel Booking. Each node has a small status badge from a recent successful test run.

Prerequisites

  • Workflows enabled for your organization. See Enable workflows for your org.
  • A booking integration in place. The workflow uses booking events from the integrated calendar provider.
  • Auto-release on no-show enabled for the relevant rooms — that's what makes the Booking No-Show trigger fire at all.

Build it

1. Create the workflow

From the Workflows list click New workflow, name it Cancel abandoned recurring meetings, and open the editor.

2. Add the Booking No-Show trigger

  1. Click Add node → Triggers → Booking No-Show.
  2. No configuration needed — it fires for every no-show in the org.

3. Add the recurring-and-has-master guard

  1. Click Add node → Conditions → If.
  2. Inspector: combine operation All, two rows:
    • Row 1: {{ .trigger.event.isRecurring }}boolean is equal to true.
    • Row 2: {{ .trigger.event.masterId }} string is not empty.
  3. Wire the trigger to the If's input.

The guard ensures we only count and cancel for recurring events that have a master to cancel. Singleinstance no-shows skip through (false port unconnected — workflow ends).

4. Add the Counter

  1. Click Add node → Actions → Counter.
  2. Inspector:
    • Operation — increment.
    • Delta — 1.
    • Key — noshow:{{ .trigger.event.masterId }} (the per-series scope).
  3. Wire the true port of the If to the Counter's input.

The counter persists across runs. Every no-show on the same recurring series increments the same key.

5. Add the threshold check

  1. Click Add node → Conditions → If.
  2. Inspector: one row — pick count from the upstream Counter node via the data-reference picker, operation number is greater than or equal to, value 20 (or whatever threshold you want).
  3. Wire the Counter to this If's input.

6. Add the Cancel Booking action

  1. Click Add node → Actions → Cancel Booking.
  2. Inspector:
    • Event ID — {{ .trigger.event.masterId }}. This is critical. Cancelling the master deletes the whole series; cancelling event.id would only delete this one occurrence (and the next one would no-show, then the next, then the next…).
    • Cancellation message — something honest like Cancelled automatically after 20 no-shows. Reach out to facilities if you'd like to re-book..
    • Notify attendees — UPDATE_ALL.
  3. Wire the true port of the threshold If to this action.

7. Test it

  1. Click Run workflow.
  2. The trigger picker opens — pick Booking No-Show (this workflow only has one trigger anyway).
  3. Edit the trigger payload to fixture an occurrence of a recurring series: 
    {
      "event": {
        "id": "occ-test",
        "subject": "Weekly architecture sync",
        "space": {"id": "sp-room-a", "name": "Room A"},
        "organizer": {"email": "you@example.com"},
        "isRecurring": true,
        "masterId": "master-arch-sync",
        "type": "occurrence"
      }
    }
  4. Run it. The counter for master-arch-sync increments to 1. Threshold is 20, so the workflow stops there. No real booking is cancelled. Run it 19 more times (or temporarily lower the threshold) to exercise the cancel path against a fixture event id.

8. Save and enable

Click Save, leave Enabled on, write a commit message ("Cancel abandoned recurring series after 20 no-shows"), and the workflow takes over.

A note on "in a row" vs "total"

This workflow counts total no-shows on a series, ever. The counter never resets.

The intuitive ask is often "5 no-shows in a row" — reset when somebody actually attends. That's harder than it looks, and the limitation is honest:

  • The Booking Ended trigger fires whether the meeting was attended or auto-released. So wiring "Booking Ended → reset counter" resets after every meeting, including no-shows — defeating the count.
  • A reliable "attended successfully" signal doesn't exist today.

So pick a high "total" threshold (20 weekly occurrences ≈ five months of no-shows — a strong signal the meeting is abandoned) rather than a low "in a row" threshold. If you want "in a row" properly, that needs a new trigger or a released flag on the Ended payload — both tracked as follow-ups.

Why cancel, not decline?

Two different operations, very different outcomes:

  • Cancel (what this action does) removes the event for everyone. The series is gone.
  • Decline-as-resource leaves the event on the organizer's calendar with no room — the organizer typically rebooks a different room and the same pattern repeats next week.

For chronic no-shows, cancel is the operationally useful answer. If you want to encourage the organizer to clean up rather than remove the booking yourself, manual outreach beats a workflow.

Variations

  • Different thresholds per building. Chain an Is In Building check before the Counter and set a different threshold for each. Or build one workflow per building.
  • Notify the organizer instead of cancelling. Swap Cancel Booking for Send Direct Message to {{ .trigger.event.organizer.email }}, with a message like "This recurring meeting has had no-shows. Should it still be on the calendar?". Less destructive.
  • Combine with a Cooldown. Wrap the cancel in a Cooldown so the same series can't be cancelled twice if something races. (Probably overkill — DeleteEvent on a non-existent event is a no-op.)

When it doesn't fire

If you expected the workflow to cancel a series and it didn't:

  1. Executions tab: is the trigger firing? If not, check that auto-release on no-show is enabled for the room and that the booking provider is healthy.
  2. Expand each step. The first If should route true; the Counter should show the incremented value; the threshold If should route based on that value.
  3. If everything else looks right but the Cancel step failed with "Workflow has no service account configured for this action", the workflow is missing its service-account binding — talk to your Neowit admin.
  4. If the Cancel step failed with a provider error, the calendar provider rejected the delete. Check the message — usually a permissions issue against the resource calendar.

Related