Runs

​

What are runs?

A run is a group of related bookings that happen together, at the same time. Think of a run as the actual tour departure—the physical event where guides show up, passengers arrive, and the experience happens. For example, if you have a morning kayak tour at 9:00 AM, that’s one run. Multiple customers might book that same tour, and each booking creates an event. All those events belong to the same run because they’re happening together. Another example: a private tour for the Smith family and a private tour for the Jones family might be separate bookings (separate events), but if you decide to combine them and run them together with the same guides at the same time, they become part of the same run.

​

Runs and events: a two-level model

Helm organizes bookings using two connected concepts: runs and events. Events are individual bookings. When a customer makes a reservation, that creates an event. Each event has its own passengers, contact information, pickup details, and booking-specific information like experience type, rate, and status. Runs are containers for one or more events. Every event must belong to a run—events cannot exist independently. When you create an event, Helm automatically creates a run for it, or adds it to an existing run if you’re booking into an already-scheduled departure. This two-level structure exists because tours have both booking-level information (specific to each customer) and operational-level information (shared across all customers on that departure). By separating these concerns, Helm can manage both individual bookings and the logistics of running the actual tour.

​

What belongs to runs vs events

Understanding what lives at the run level versus the event level helps you know where to look for information and where changes will apply. Run-level resources are shared across all events in the run:

• Guide assignments – which guides are leading this departure
• Tickets – inventory allocation for the run
• Comments and comment drafts – operational notes about the run
• App invitations – invitations sent to guides or staff
• Google Calendar event – the calendar entry for this departure

When you assign a guide to a run, that guide is assigned to all events in the run. When you add a comment to a run, it’s visible in the context of the entire departure, not just one booking. Event-level resources are specific to each booking:

• Passengers – who’s coming on this booking
• Main contact – the customer contact for this booking
• Pickup details – where to pick up these passengers
• Notes – booking-specific information (these sync across events in the same run, so all events share the same notes)
• Experience – which tour/activity this booking is for
• Rate – pricing for this booking
• Status – whether this booking is confirmed, cancelled, etc.
• Language – preferred language for this booking

This separation means you can have multiple different bookings (different passengers, different contact information, different rates) all part of the same operational departure with shared guides and logistics.

​

Primary events

When a run contains multiple events, Helm needs to know which event’s information to use for run-level details like the run title, experience type, rate, and pickup information. The event that serves this role is called the primary event (sometimes called the canonical event). The primary event is the source of truth for:

• Run title and display information
• Experience type shown at the run level
• Default rate and pricing information for the run
• Reference pickup details

You can explicitly set which event should be primary, giving you control over which booking’s details represent the run. This is useful when you have multiple events in a run but one booking is more “official” or complete than the others. If you don’t set a primary event, Helm will automatically elect one using an algorithm that considers:

1. Origin – events created directly in Helm are preferred over imported events
2. Completeness – events with more complete information are preferred
3. Recency – more recently created or updated events are preferred

When events are merged into a run or when the current primary event is removed, Helm re-evaluates and may elect a new primary event automatically. You’ll see which event is primary in the run details view, and you can change it if needed to ensure the right booking’s information represents the run.

​

How runs are created

Runs are created in two ways: Automatically when events are created – When you create a new booking (event), Helm automatically creates a run to contain it. This happens whether you’re creating a booking manually, importing from a reservation system, or receiving a booking from an online booking widget. Manually by merging events – You can take multiple existing events (each in their own run) and merge them together into a single run. This is useful when you have separate bookings that you want to operate as one departure. See the merge and unmerge documentation for details on how this works.

​

Run statuses

Runs have statuses that indicate their operational state: OK – The run is in a consistent, normal state. All events in the run are compatible and the run is ready to operate. INCONSISTENT – The run has issues that need attention. This typically happens when:

• Events in the run have been partially cancelled (some events are cancelled, others are not)
• Events have conflicting information that makes them incompatible
• The run’s data is out of sync in a way that needs manual resolution

When you see an INCONSISTENT status, review the run’s events to understand what’s causing the inconsistency. You may need to unmerge events, cancel additional events, or resolve conflicts between event data. Other statuses may appear based on the state of events in the run, such as when all events are cancelled (the run is fully cancelled) or when events are in different booking states.

​

Runs in the UI and calendar

Throughout Helm, you’ll interact with both runs and events depending on the context. In calendar views, you see runs. Each block on your calendar represents a run—a departure that’s happening. When you click into a calendar entry, you’re viewing a run and can see all the events (bookings) that are part of it. In booking lists and detail views, you often work at the event level. When you view or edit a booking, you’re working with an event. The event detail view will show you which run it belongs to and let you access run-level information like guide assignments. Run detail views show you the complete picture: all events in the run, the guides assigned, tickets allocated, comments, and other run-level resources. You can see how many passengers are coming in total, which bookings are part of the departure, and manage the operational details. The interface makes it clear whether you’re viewing/editing run-level or event-level information, helping you make changes at the right level.