Capitan Release Notes - September 28, 2026

What's in this release

Documents can now email customers before and when they expire, with a new Documents report to find them, and staff get more control over event invitations and bookings, from exact invitation deadlines to per-booking deposits, alongside new booking details on the reports, server-side purchase tracking for Meta and Google Analytics, and a number of smaller changes and fixes.

Documents

Events and bookings

Reports, Chart Builder and dashboards

Sales, payments and memberships

Climber App and integrations

Plus a number of fixes, at the end of this article.

Documents

Document templates: emails before and when a document expires

Previously, nothing told a customer that their waiver or other document was about to expire, or that it had. They found out when they were stopped at check-in, or when staff noticed the expired badge on their profile.

A document template's Settings tab now offers two optional emails, beneath the existing expiration settings: "Send an email before this document expires" and "Send an email when this document expires". The first asks for Days before expiration, from 1 to 365, defaulting to 14. Each email has its own Note to include in the email, and its own "Include a button to complete the document again" option, which, for templates available in the Climber App, adds a button that opens the document for the customer to complete without signing in; Button text changes the button's wording from the default "Complete a New Document". Preview Email shows the email as it stands, unsaved changes included, without sending anything; a new template must be saved once before it can preview. Templates are on the Document Templates page.

Both emails are off by default and can be used independently. Every active customer on the document who has an email address receives it, including the signing adult on a family waiver whose children have no address; an address shared by several people on one document gets one email. Emails go out between 9am and 10am in your organization's time zone, once per customer per document. A minor's waiver that expires when they come of age counts as expiring like any other.

Turning an email on reaches documents already inside its window. Switching on the before-expiry email, or lengthening its lead time, emails every customer whose document already falls inside the window on the next morning. Switching on the expired email also emails customers whose document expired within the past week. Check the note and the lead time before saving on a template many customers have signed.

No email is sent once the people on the document have completed a newer copy from the template, including one still awaiting staff approval. Denied, invalid and pending-approval documents never trigger either email, and the settings apply to every document completed from the template, whichever version the customer signed.

New report: Documents

Previously, a document's status and expiration date could only be checked one customer at a time, on their profile.

The new Documents report, in the Customers category of Reporting, lists every completed document with one line per customer on it, so a family waiver covering three people appears three times. The default columns are Customer, Role, Document, Date Signed and Status, where status is one of Valid, Pending Staff Review, Denied by Staff, Expired or Invalid. Further columns cover the expiration date, the template version, where the document was completed, proficiencies and staff approval. Documents from retired templates are included.

The Expiration Date filter offers upcoming ranges: Next 7 days, Next 30 days, Next 90 days, Next month and Next quarter. Combined with the Valid status, it answers "whose waiver expires this month?", for example to remind those customers at the desk.

The report supports saved views, column choice, CSV export and emailed reports, the same as the other tabular reports.

Events and bookings

Event invitations: set a specific expiry date and time

Previously, the invitation windows asked only how many hours the participant had to accept. A deadline such as "every invitation expires on the 1st" meant working out a different hour count for each batch, with nothing on screen showing the resulting date.

The Invite Customer to Event, Invite Participants to Another Event and Invite to Roster windows now offer Number of hours, the default and unchanged, or Specific date & time. Picking a date fills the time with 11:59 PM, which you can change. The time is in the time zone of the event's or roster's location, which is named under the field. The invitation email states the date and time, the invitation expires at that moment, and everyone invited in one submission gets the same deadline.

Invite Off Waitlist now shows its optional Booking Deadline field on the first send, not only when resending. Left blank, the event type's usual acceptance window applies.

Waitlist expiry times now show in the location's time zone. They previously showed in each viewer's own browser time zone, so a staff user in another time zone saw a different time from the one customers were told. Both the event's waitlist and the event type's waitlist page now match the invitation email.

Waitlists and invitations are covered in Creating and Managing Waitlists.

Staff bookings: set the deposit for a booking

Previously, an event's deposit came from its pricing matrix and was the same for every customer. A family on a payment arrangement, or one that wanted to pay in full for an event with a deposit, had to be handled outside Capitan.

When staff book a customer with "Book participant via Climber App to collect payment and participant details", the payment page now shows Deposit for this booking (staff only). Enter any amount from 0 to the full total and click Apply: 0 books with nothing collected now, and the full total charges everything now. This works whether or not the event has a deposit configured, so a $300 program with no deposit can be booked with $150 today and $150 later.

Any amount below the total behaves exactly like a configured deposit. The booking is marked deposit paid, the usual confirmation and receipt emails go out, and the customer can pay the rest from My Bookings in the Climber App. A deposit of 0 still counts as a deposit paid, so the booking is not cancelled automatically as unpaid.

Customers booking themselves never see the field and always pay the pricing matrix's deposit. The deposit can only be set at booking time, not changed on an existing booking.

Direct bookings: choose whether the booking includes facility entry

Previously, whether a booking let its participant into the facility was worked out at check-in, by matching the booking's fee name against the event's current pricing matrix. A direct booking has no fee, so it never granted entry, and a booking whose fee was later renamed or removed quietly stopped granting entry, with staff left to choose Provide Free Entry at the desk.

The Create Booking window now shows Booking includes facility entry when you choose "Book participant directly onto event without collecting payment or additional participant details". It starts checked when every fee on the event's pricing matrix includes entry, and unchecked otherwise. A participant booked with it checked is admitted at check-in like anyone else.

Entry is now saved on the booking when it is made. Renaming or removing a fee, turning off a fee's entry setting, or changing whether vouchers include entry no longer changes bookings already made; changing a booking's own fee recalculates it. Direct bookings made before this release still grant no entry.

Roster invitations: see the pro-rated first bill before sending

Previously, nothing on a roster invitation said that choosing a start date would pro-rate the participant's first bill, or by how much, so staff learned of it when the participant asked about a smaller first charge.

Once a roster is chosen, and its membership bills on a fixed day of the month, a note under Start Date (optional) says the first bill will be pro-rated. After you pick a start date it shows the dates the first bill covers, what share of the billing period that is (for example "11 of 30 days"), the plan's base fee and the pro-rated first bill at that fee. When the start date is the billing day, it says the first bill is a full period instead. The note appears in Invite to Roster, Invite Waitlist Entry To Roster, and Invite Participants to Another Event when the invitation is to a roster.

The figures are the base fee only. They do not include tax, the initiation fee, discounts, add-ons or upfront payment options, which the participant may choose at checkout. The note is informational and never changes what is sent.

Climber App: hide the spots open count on event listings

Previously, the Climber App schedule always showed how many spots were left on each event. For an event meant to sell out, a large number open can take the urgency out of booking.

Organization Settings now has Show remaining capacity ("spots open") in Climber App event listings in its Climber App Settings section, on by default. Each event type can override it with Show remaining capacity in Climber App listings on its edit page, choosing Use organization setting, Yes or No. When the count is hidden, nothing replaces it: Fully booked, Waitlist only and Booking closed still show as before. Event types are reached from Event Setup.

The waitlist count setting now works. An event type's "Should the waitlist count be displayed in the Climber App?" setting previously had no effect. Set to Yes, and with customers allowed to join the waitlist, the Climber App now shows how many people are waiting: next to Waitlist only on the schedule, on the event type's page, and on the join-waitlist pages. If an event type was already set to Yes, customers see the count from this release on.

Reports, Chart Builder and dashboards

Bookings and Reservations reports: new Booking Details and Reservation Details

Previously, a row on the Bookings or Reservations report was all there was to see. A staff direct booking showed "Not linked" as its booking customer with no participant named anywhere, so finding out who was on it meant matching Booking IDs across both reports.

Every row on the Bookings and Reservations reports now has a View button. Booking Details shows the event, date and location, the booking's status and customer, how it was made (by the customer, by a named staff user on their behalf, as a direct booking, by a roster membership, or from a private event request), every fee, payment, refund and voucher with links to each payment's details, the booking's question responses, and every participant with a View link to their reservation. Reservation Details shows the participant, each session with its check-in status, question responses and the other participants, and links back to the booking.

The same windows open from the customer profile's Reservations tab. They are read-only; checking in, rebooking and cancelling stay on the event's page. Each window's address can be copied and shared, and opens straight to that booking or reservation.

Previously, a booking payment on the Payments report read "Booking: Youth Team" as plain text in the Invoice Description column, and Payment Details had no link either, so finding the booking meant searching the Bookings report by hand.

When a payment is for a single booking that has not been cancelled, Invoice Description is now a link that opens the booking's Booking Details in a new tab, including in emailed Payments reports and dashboard tables. In Payment Details, a line item for a booking now links to that booking. The links work whether or not the payment has a linked customer.

Line items for private event bookings made from the Staff Site previously showed an amount with no description. They now carry one, existing ones included, so receipts and Payment Details show text.

Chart Builder: Payment Failed in the Membership Count metric

Previously, a membership whose renewal payment failed counted as neither Active nor Frozen in the Membership Count metric. On a bill date when many renewals failed, the chart dropped as if those members had cancelled, even though they were still on the books and could be recovered.

The metric's Status filter now offers Active, Frozen, Payment Failed, Active + Frozen and Active + Frozen + Payment Failed. Payment Failed counts memberships whose renewal or freeze-fee payment failed. A payment that is still processing continues to count under Active or Frozen; one that is still pending is not counted under any status. Active + Frozen + Payment Failed is the total of memberships still on the books. Active remains the default, so existing charts are unchanged, and history goes back as far as the other statuses.

The Membership Counts Over Time and Membership Add-On Counts Over Time reports each gain a Payment Failed count column option, unchecked by default.

Every metric type, including Membership Count, is covered in Chart Builder: Metric Types Explained, and the report in Report: Membership counts over time.

Chart Builder: name a chart without saving it

Previously, a chart could only be named by saving it. A chart shared as a link arrived as "Untitled Chart", and the same link pasted into a dashboard tile or an emailed report had to be named again by hand.

A pencil icon next to the chart's name in the Chart Builder, Rename chart, turns the name into a text box: Enter or clicking away keeps the new name, and Esc cancels. The name travels with the chart's link, so a colleague opening it sees the name you gave it, and a dashboard tile or emailed report created from a pasted link or source takes the chart's name automatically. On a saved chart, the new name is kept once you click Save and then Update Chart.

The pencil is disabled while the Source tab has unapplied changes; apply or revert them first. Links shared before this release still open as "Untitled Chart".

Dashboards: Entry Passes tables follow the Locations override

Previously, a dashboard's Locations override had no effect on Entry Passes tables, so a dashboard set up for each location's manager still listed every location's passes.

An Entry Passes table on a dashboard now shows only passes sold at the selected locations while the override is set. Passes with no sale location, such as passes granted without a sale, are left out while it is active.

On the Entry Passes report, Edit Filters now offers a Sale Location dropdown in place of the Sale Location Name text box. Saved views that use the old text filter keep working.

Sales, payments and memberships

Staff Site sales: locked while a payment is in progress

Previously, a Staff Site sale could be edited while a card reader was waiting for a tap, and the reader charged whatever amount it was first sent. Sending $60 to the reader, applying a discount, and sending $30 could end with the customer tapping and paying $60 on a $30 sale.

While a card-reader or payment-link payment on a sale is pending, the sale page now shows a Payment in progress notice with the amount and when it started. Adding or removing items, applying a discount code, and changing the customer or location are all blocked, automatic discounts are not recalculated, and a second payment, on a card reader or a payment link, is refused. The lock lifts on its own when the payment completes, fails or is cancelled. A payment request sent to the customer through the Climber App also blocks changes to the sale until it is cancelled.

Discard Pending Payment clears a payment that will not be completed. If the payment processor cannot cancel it, the sale stays locked until the payment finishes. Its confirmation reminds you to check that the card reader is no longer showing the sale before sending a new one; if the reader captures the payment anyway, it is still recorded against the sale. Each discard is recorded in the activity log with the staff user and the amount.

Booking payments: linked to the participant when nobody is named on the booking

Previously, a payment for a booking with no booking customer, such as a parent accepting an invitation without signing in, showed "Not linked" under Linked Customer on the Payments report and appeared in nobody's payment history. No receipt was emailed for it either.

When such a booking has exactly one participant with a customer profile, the payment is now linked to that participant and appears in their payment history. The revenue is attributed to them too, so Lifetime Value and other purchaser-based reporting count it. The receipt is emailed to the address entered on the reservation at checkout, or the participant's profile email if none was entered. A card-reader payment sent for a booking is also now linked to the booking's customer, or to that sole participant.

The booking itself is unchanged: the participant does not become its booking customer and cannot manage or cancel it.

Payments from the past year were linked too. Booking payments that meet the same rule now show the booking customer, or else the participant, rather than "Not linked", so figures grouped by customer on the Payments report and Lifetime Value can shift for those customers.

Customer profile: new Edit Bill Date action for recurring memberships

Previously, the only way for staff to move a recurring membership's bill date was Edit Start Date, available only within 28 days of the start and before the first renewal. Anything later had to go through Capitan support.

A recurring membership's Edit menu on the customer profile now includes Edit Bill Date, for memberships that have started, are active and are not awaiting staff approval. Choose a new bill date, tomorrow or later, and optionally add notes. The next renewal charges on that date. For monthly, quarterly, half-yearly and yearly memberships, the chosen day of the month becomes the customer's billing day from then on, even if the membership type normally bills on a fixed day.

No prorated charge or refund is made. Moving the date later gives the customer days they have not paid for, and moving it earlier takes away days they have paid for; add account credit separately to make up the difference. Event vouchers that expire on the current bill date move to the new one.

The action is not offered while a cancellation or freeze is scheduled; undo it, change the bill date, then reschedule. The change is recorded in the activity log with the old and new dates, and the customer is not notified.

Climber App and integrations

Climber App: a parent's email stays on the parent's account

An email address can only belong to one customer. Previously, when a parent and child shared an address, it could end up on the child's account, leaving the parent with none. This happened when a parent entered a child's name and birthday with their own email while buying as a guest, or when the child's profile already held the address, and a waiver completed afterwards saved the parent without it. The parent then could not be emailed or invited to the Climber App.

Four changes close this off:

  • The Enter Your Info step of a guest purchase now refuses a birthday under 13, explaining that the purchaser enters their own details and chooses who the purchase is for on the next step.
  • When a waiver gives a minor the same email address as an adult on that waiver, the address is saved on the adult only.
  • When a waiver or guest purchase uses an address held by a minor's account that has never had a password or a Climber App invitation, the address moves to the adult. Both profiles' activity logs record the move.
  • Redeeming a gift or a redemption code always offers Someone Else (Enter Manually), so a parent can redeem for a child without entering the child as the purchaser.

Profiles already affected were repaired where a completed document recorded the address in the adult's own section. An address is never moved off an account that has a password or has been invited.

How email addresses move between profiles is covered in A customer filled out a document with their email, but the email isn't populating on their profile.

Meta: send events from Capitan's server with the Conversions API

Previously, Climber App events blocked by ad blockers or browser tracking prevention never reached Meta, so organizations running Meta ads saw fewer conversions than the sales Capitan actually processed.

Organization Settings now has a Conversions API Access Token field in the Meta section, which appears once a Meta Pixel ID / Dataset ID is entered. With a token saved, Capitan also sends ViewContent, InitiateCheckout and Purchase from its own server, each paired with the browser's copy so Meta counts it once. A purchase is sent even when the payment completes after the customer has left the page. Clearing the token turns this off.

The customer's privacy choice still applies: nothing is sent from the server for a visitor who has not consented, for staff booking on a customer's behalf, or for a kiosk. If sending keeps failing, the field says so: a This integration needs attention notice appears next to it with the error, and sending pauses until a new token is entered. Organizations without a token see no change.

Google Analytics: send purchases from Capitan's server

The same gap applied to Google Analytics, where blocked purchases went uncounted. A new Measurement Protocol API Secret field, which appears once a Google Analytics 4 Measurement ID is entered in Organization Settings, sends each Climber App purchase from Capitan's server as well, matched to the browser's copy so Google Analytics counts it once. Only purchases are sent, because Google Analytics cannot match other events against their browser copies.

Google Analytics accepts a wrong secret without any error, so Capitan cannot warn you about one. Make a test purchase and watch it appear in Google Analytics Realtime to confirm the setup.

The two integrations are covered in Meta Pixel for the Climber App and Google Analytics for the Climber App.

Fixes

  • Bulk Download stopped partway through without saying so. When a membership type had no members in the chosen period, it stopped at Membership Counts Over Time and skipped every report after it; every selected report now downloads, and one that fails is named in the window.
  • Reviewing a membership awaiting staff approval showed "Membership Not Found" when it had been paid for but was awaiting a payment method. It now opens and appears in the Inbox's Memberships Pending Staff Approval queue, and the Memberships report's Awaiting Payment Method filter, which returned nothing, now finds these memberships.
  • Customer profiles listed Removed passes from Staff Site sales that were never paid for. Passes from a cancelled sale no longer show, and cancelling a sale now removes the unpaid items it created.
  • A receipt could show a negative tax rate when a discount put a price on a half cent. The line item, pre-tax amount and total now agree, and recent affected invoices were corrected.
  • Payments made with a gift card by customers who had not signed in were not linked to them. They now appear under Linked Customer and in the customer's payment history, including payments from the past year.
  • Reopening the payment page for a membership awaiting a payment method, or choosing a saved bank account there, could change its already-paid first invoice, for example by adding a bank account discount. A paid first invoice is now left as it was, and such a discount applies from the next bill.
  • Use Saved Payment Method did nothing on the emailed link to finish setting up a membership. It now saves the payment method and activates the membership, as it does for a signed-in customer.
  • Gravity payments from a saved bank account showed as Credit Card (Gravity). They now show as Bank Account (Gravity) on the Payments report, in exports and on receipts, existing payments included.
  • Opening a details window from a Staff Site table scrolled the page back to the top. The page now stays where it was, on Payments and every other table with a details window.
  • A name or email containing an emoji could stop a booking, waiver or sign-up with an error page. The emoji is now removed and the rest of the value kept; a name made only of emoji is asked for again.

Still need help? Contact Us Contact Us