Season Ticket Renewals

The renewals feature manages the full lifecycle of season ticket renewals, from configuring renewal windows and date based automation, to tracking subscriber decisions and communicating outcomes to your CRM. This article covers how renewal statuses work, what triggers each status change, and what both admins and subscribers can do at each stage.

Renewals currently support fixed-seat packages only, where a subscriber holds the same seat for every performance in their package. Flex package support is on TixTrack's 2026 roadmap.

Prerequisites

Before renewals can function, each season package must have two things in place:

• Season - a date range that covers all events in the package. The season's status (upcoming, active, or ended) drives key system behavior around renewals, ticket exchanges, and transfers.
• Series - a named grouping that defines what kind of subscriber they are (e.g. "Wednesday Evening," "Tuesday Matinee"). The series is created under Manage Renewals, then selected on the package.
  • When setting up a renewal for an upcoming season, always select an existing series from the dropdown. Do not create a new one. This ensures subscriber records roll over correctly from the active season.

Both a season and a series must be present on a package for a subscriber record to be created. Without both, no subscriber record is generated and no webhooks fire to your CRM.

Renewal statuses

Each subscriber has a renewal status that reflects where they are in the renewal lifecycle. The renewal status is what displays in the UI. In the admin customer record under the Season Packages tab, and in the Customer Login "Account" page. Because the status field overwrites itself over time, the subscriber history table is the running log of all changes.

How NonRenewed relates to Lapsed and Declined

NonRenewed is not a status a subscriber moves into directly from Pending. The flow always goes through Lapsed or Declined first:

• Subscriber takes no action → Lapsed (at renewal end date) → NonRenewed (at lock date)
• Subscriber declines → Declined → NonRenewed (at lock date)

The lock date is the only point at which seats are released back to open or hold. Until then, both Lapsed and Declined seats remain reserved.

How subscribers move from New or Renewed to Pending

Subscribers stay in New or Renewed status until all three of the following conditions are met:

1. A new package is created.
2. The season on that package is set to a future date range.
3. A series is associated with the new package, and that series is also associated with the currently active package.

The series association is the trigger. If the season is already active when the series is added, nothing fires. If the season is future but no series is added, nothing fires. Both conditions must be true at the same time.

Key dates and what they trigger

Renewals are driven by a set of configurable dates set on the season package. Each date triggers specific status changes and system events automatically.

Renewal start date

• Opens the renewal window for subscribers
• The renewal option becomes visible in the Customer Login "Account" page and on the admin customer record (Season Packages tab)
• Auto-renew start is typically set to the same date as renewal start

Renewal end date

• Any subscriber still in Pending status moves to Lapsed
• Seats remain reserved, they are not released at this point
• SubscriberUpdated webhook fires; history action logged as Lapse
• Admin retains the Renew button on the customer record to enable win-back outreach
• Removes the Renew button from the consumer-facing portal only, this is a UX change, not a status change

Lapsed end date

• Does not change the subscriber's renewal status
• No webhook fires and no history event is logged
• Removes the Renew button from the admin customer record

Lock date

• Impacts subscribers in Lapsed or Declined status only
• Both statuses automatically move to NonRenewed
• Seats are released:
  • If no hold exists on the seat → seat returns to OPEN
  • If a hold exists on the seat → seat returns to HOLD
• SubscriberUpdated webhook fires; history action logged as RenewalLocked

Season end (active season)

• Any subscriber with NonRenewed status moves to SubscriberStatus = Inactive
• If they purchase again in a future season, they are treated as a brand new subscriber record
• SubscriberUpdated fires; history action logged as Deactivate

Subscriber actions and webhooks

When a subscriber or the system takes an action on a renewal, the following webhooks and history events are generated and communicated to Salesforce:

Admin capabilities

Admins have additional controls available throughout the renewal lifecycle:

• The Renew button is available on a subscriber's customer record under the Season Packages tab. It remains available for Declined and Lapsed subscribers throughout the renewal window and up until the Lapsed End Date, enabling win-back outreach even after the consumer-facing Renew button is removed at the Renewal End Date. After the Lapsed End Date, the Renew button is no longer available on the admin customer record.
• All key dates are configurable per package: Renewal Start, Renewal End, Lapsed End, and Lock Date.
• Payment cards can be saved on behalf of patrons for auto-renew opt-in and payment plans, in both new purchase and renewal flows.
• Auto-renew opt-in/out is manageable from the patron portal. The admin auto-renew opt-in mirrors the consumer flow.

Onboarding new subscribers (first-year setup)

When importing subscribers from an external system for the first time, a shell package is used to get subscribers into the system in the correct state. A shell package has a series and a season but no actual events.

• Set the season start and end dates in the past, exact dates don't matter beyond that
• Assign the series that aligns with the upcoming active package's series.
• Do not add any events, the shell package's only purpose is to create subscriber records in Pending status.
• Once imported, for example the 25/26 shell package series must align with the 26/27 series so records roll over correctly.

Subscriber history table (Salesforce)

The renewal status field overwrites itself each time a subscriber's status changes. The subscriber history table is therefore the source of truth for a subscriber's full lifecycle, every action, date, and status change is logged there as a separate record.

This history is communicated to Salesforce in real time, so Salesforce maintains its own running log of subscriber status, renewal type, and all history actions. The history table is not currently surfaced in the consumer-facing portal.