Capitan Release Notes - April 24, 2026

What's in this release

Customizable columns and Saved Views in Reports
Favorite Reports and Recently Viewed Reports
Event Type setting: require an active waiver
Event Type waitlist counts at a glance
Membership discount policy: required active duration

Plus several fixes — see the end of this article.

Customizable columns and Saved Views in Reports

The Reports area has a major overhaul this release. Each supported report now has two new options in the upper right corner:

Configure Columns: allows the report's set of columns to be customized and reordered.
Saved Views: allows you to switch between saved views, or create a new view from the currently-configured columns and filters.

Each Saved View bundles a name, a set of columns (in your chosen order), and the current report filters. The built-in Standard Capitan View is always available and cannot be edited or removed; any number of additional views may be added on top of it. Each report has a Default View that determines what loads when the report is first opened.

Saved Views are organization-wide — a view created by one staff member is available to everyone — making it straightforward to standardize how a team looks at a report (for example, a "Monthly recurring revenue, all locations" view for the finance lead, or a "Today's check-ins" view for the front desk).

Default views are individual to each staff user, so setting your default view will not impact what other users see when they open the report.

The following reports support customizable columns and Saved Views in this release:

Favorite Reports and Recently Viewed Reports

Two conveniences in the Reports list:

Favorite Reports: each user can choose which reports appear in this section at the top of the list, and in which order.
Recently Viewed Reports: the Reports list also surfaces the reports each staff member has opened most recently, so the report you were just looking at is always a click away.

Both lists are per-staff-user, so each team member's selections are their own.

Event Type setting: require an active waiver

There is a new setting on each Event Type: "Require participant have any waiver valid at the location of the event?" (Yes/No, default No).

When enabled, every participant on a booking for that event must have an active waiver valid at the event's location before the booking can be completed. If a participant does not, the Climber App now includes a new waiver step in the booking flow — the same format as the existing participant agreement step — that prompts the booking customer to fill out the waiver document configured for that location.

A few details worth noting:

A single waiver document template may be designated as the "valid waiver" for each location.
If a location has no waiver document template configured, the policy is not enforced for events at that location.
The new waiver requirement is independent of the existing participant agreement setting — both can be required on the same event type. To accommodate this pairing, the Participant Agreement section on the Event Type setup page has been renamed to Required documents to complete booking, and now contains both the existing participant agreement setting and the new active-waiver setting.

Event Type waitlist counts at a glance

In the Event Type Waitlists view, each event type now displays its current waitlist count alongside its existing summary information. This makes it much easier to see at a glance which programs have demand piling up, without having to drill into each event type individually.

Membership discount policy: required active duration

When configuring a membership discount, there is a new field: Required active duration (days).

> If configured, a membership must have been active for the chosen number of days before it qualifies for this discount. Time during which the membership is frozen will not count towards the number of active days.

Some details on how this works:

Active days are counted as the total number of days the membership has been active since it was purchased. Frozen periods are excluded from the count, but freezing the membership does not reset progress — active time before the freeze still counts.
Discounts are evaluated against the membership's next end date, not the current date — so if the next bill will fall after the threshold is crossed, the discount is shown on that bill even if the threshold has not yet been reached today.

This is useful as a form of membership lock-in without requiring contracts: for example, a loyalty discount that only kicks in after a member has been active for six months.

Fixes

Lightspeed gift card integration restored. Lightspeed retired its previous gift card API endpoints in favor of new "2026-04" endpoints. Capitan has been updated to use the new endpoints, restoring the Lightspeed gift card integration (gift card sales, redemptions, and balance lookups).