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

Triggers

Triggers are the starting point of every workflow — the event that says "now run this." For anyone picking the right starting event for a workflow.

How triggers work

You can only have one trigger per workflow, and it has to be the leftmost node (nothing connects into it). Every time the trigger's event happens, the workflow runs once, from that trigger through to the final action.

Triggers fall into two broad groups:

  • Event triggers fire when something happens in Neowit or a connected service (a booking, an occupancy change, …).
  • Schedule triggers fire on a clock — once every 15 minutes, every Monday at 8 AM, a cron expression of your choice.

Event triggers

Event triggers come from apps inside Neowit that are publishing events. Today this includes:

Booking events

  • Booking No-Show — a booked meeting was marked no-show.
  • Booking Started — a meeting just started.
  • Booking Ended — a meeting just ended.
  • Booking Not In Use — a booking was released because nobody used it.

Each carries the full event payload: id, subject, space.{id, name}, organizer.{id, name, email}, plus the flags isRecurring and isAutoBooked. Use those fields in conditions and action templates.

Occupancy events

  • Space Occupied — fires when a space becomes occupied.
  • Space Not Occupied — fires when a space becomes available.

Both carry the same payload shape: the space's id and name, plus isOccupied (a boolean — true for Space Occupied, false for Space Not Occupied).

There's also a Space Is Occupied condition you can drop in elsewhere to check a specific space's current state.

Schedule triggers

If you want the workflow to run on a clock, pick Schedule. In its settings you choose a schedule type:

  • Every N minutes — great for frequent polling.
  • Every N hours — hourly-ish checks.
  • Every N days — daily at a specific hour and minute.
  • Weekly — specific days of the week at a specific time.
  • Monthly — specific day(s) of the month at a specific time.
  • Cron — for the specialist; full cron expression with timezone.

All schedule types take a timezone so you don't have to think in UTC. "Every day at 09:00" means 09:00 in the zone you pick.

[SCREENSHOT] Schedule trigger settings panel showing the "Every N days" option selected, with fields for timezone (Europe/Oslo), days=1, triggerAtHour=9, triggerAtMinute=0.

Referencing trigger data later

Every node downstream can read from the trigger's data. In an action's settings field, click the data-reference icon and navigate trigger → …. You get:

  • Everything the trigger itself carried (the event payload).
  • The timestamp the trigger fired.

Conditions have the same access; use it to filter what you actually want to act on.

Design tips

  • Keep triggers specific. "Booking No-Show" is better than "any booking change filtered by status" — fewer executions, cleaner logic.
  • Schedules need admin input. Running every minute is expensive; every 15 minutes or hourly is usually enough.
  • One trigger, one workflow. If you want the same action from two different triggers, build two workflows. It's clearer than nesting conditions to discriminate.

Related