Performance Scheduled Trigger Add-Ons

The standard Performance Scheduled Trigger is designed to identify and target the purchaser of a ticket. However, you can enhance this functionality with two powerful, optional add-ons.

This article outlines two "opt-in" features that allow you to expand your audience to include ticket recipients or narrow it to include only those who attended.

Additional details regarding setting up a Performance Scheduled Trigger within your Tessitura Integrated dashboard can be located in our Using Tessitura Integrated Scheduled Triggers help article.

Add-On 1: Include Recipients

When a customer buys multiple tickets to a performance, then shares some of those tickets with other constituents, the other constituents are known as recipients. This could happen in a number of different scenarios, like group sales, friend sharing, or applications (eg. True Tickets) that build their integration on the sharing of tickets.

By default, the Performance Scheduled Trigger process identifies orders that contain eligible performances, then build a data set for the owners of the eligible orders. This means that any pre or post show email communications would only go to the contact that initiated the order. This is acceptable for the majority of orders where tickets are only used by the person who placed the order. However, in a situation where tickets have been shared by the initiator with others, the communication should also go to those who have had tickets shared with them.

How to Enable the Include Recipients Add-On

To enable the inclusion of Recipients during every Performance Scheduled job run, you must set the value for P2IncludeRecipients to YES within T_DEFAULTS in Tessitura. Setting this to YES will enable recipients to be included in the data output and be eligible to receive email campaigns from associated automations. By default this value is set to NO.

The email address search hierarchy will remain the same as it is for individual order owner constituents, and additionally include the relevant contact and order info for anyone identified as a recipient on those orders. With this functionality enabled, the 2 part hierarchy will be as follows:

First, Prospect2 searches for the Owners email address to deliver to in this order:

1. An email address associated with the order.
2. An email address of defined eaddress type (P2DefaultEaddressType in T_DEFAULTS) associated with the initiator (initiator_no) of the order.
3. An email address associated with the initiator (initiator_no) of the order marked as primary.
4. An email address of defined eaddress type (P2DefaultEaddressType in T_DEFAULTS) associated with the owner (customer_no) of the order.
5. An email address associated with the owner (customer_no) of the order marked as primary.
6. An email address of the primary affiliate with the p2DefaultEaddressType.
7. An email address associated with the primary affiliate marked as primary.
8. Use the built-in Tessitura function FT_GET_EADDRESS() to identify any other potential emails in the event any of the above fail to find one (one last shot).

Secondly, Prospect2 searches for the Recipient email address to deliver to in this order:

1. An email address of defined eaddress type (P2DefaultEaddressType in T_DEFAULTS) associated with the recipient.
2. An email address associated with the recipient marked as primary.
3. An email address of the primary affiliate of the recipient with the p2DefaultEaddressType.
4. An email address associated with the primary affiliate of the recipient marked as primary.
5. Use the built-in Tessitura function FT_GET_EADDRESS() to identify any other potential emails in the event any of the above fail to find one (one last shot)

Add-On 2: Filter by Performance Attendance

For post-show communications, you may want to exclusively message patrons who actually attended an event. This optional feature refines your audience by ensuring your trigger only includes contacts who were verified as having attended.

This is the ideal solution for sending follow-up communications like "Thank you for coming" messages, patron surveys, or special offers for future shows. By filtering out contacts who were ticketed but did not attend, you make your messaging more relevant, accurate, and personal.

How the Attendance Logic Works

When this feature is enabled, it modifies the trigger's behavior for any performance that has already occurred.

When your Scheduled Trigger runs, it first evaluates the performance date. If the performance's date and time are in the past, our logic will check the T_ATTENDANCE table in Tessitura. This table is the standard location where attendance data is stored, typically populated when a patron's ticket is scanned at the event.

Only contacts who are found in the T_ATTENDANCE table for that performance will be included in the trigger results.
Ticket holders who were not marked as attended (meaning, they do not have an entry in the table for that performance) will be excluded from the results.

This attendance check is only performed for performance based scheduled triggers with a Tessitura performance search window (step 5) set to “X days in the past”, as that indicates the event has already happened.

How to Enable the Filter by Performance Attendance

To enable attendance tracking during every Performance Scheduled job run, you must set the value for P2STTrackAttendees to YES within your T_DEFAULTS table in Tessitura.

Performance-Level Override (Bypassing the Feature)

When this add-on is enabled, there may be specific instances where you do not want to use attendance data. For example, if the ticket scanners were malfunctioning for a particular show or attendance was not recorded for an event, this override ensures your communication still goes out to all ticket holders.

To bypass the attendance check for a specific event, apply the ticketing keyword PRO2_IGNORE_ATTENDANCE to that performance in Tessitura. v260401 of the Pro2 Install script will automatically create this keyword for you in the TR_TKW table in Tessitura. When this keyword is present on a performance, the job will ignore the T_ATTENDANCE table for that show and will include all ticket holders for the given performance.