• State Not Answered
  • Replies 3 replies
  • Subscribers 264 subscribers
  • Views 64 views
  • Users 0 members are here
Options
Related

WordFly (default) email recipients from Tessitura

Martin Perks
$organization

Hi everyone,

Hope you're all well Slight smile

Martin Perks from Cheltenham Festivals (UK) here.  I'm reaching out with a dual Tessitura/WordFly query that I hope someone can help us with!


Nowadays we regularly make use of the Initiator and Alternative Email functions in Tessitura ticket orders, so that we have more fine control over the recipients of order confirmations and e-tickets (especially for Partner and Festival guest/Press tickets).  For cancelled events, we've noticed that the Event Cancellation Utility appears to respect alternative email addresses used against orders.  However, as we send the cancellation notice itself through WordFly, we're a bit unclear as to whether WordFly respects any alternatives set in Tessitura, or if it always defaults to the primary email address assigned to a constituent record used for a ticket order, regardless of Initiator etc.

Any clarification on this would be gratefully received, and thanks ever so much in advance,

Martin

  • 0 $organization

    I can think of two ways to handle this off the top of my head.  Set up your criteria for your list or extraction to pull the Recipient accounts' primary eaddress, or alternatively set up an output set that pulls the recipient's eaddresses if they exist, and that is the more complicated approach and probably would require creating a view to feed the output set. The deciding factor might be whether you can live with the record of the email  on the recipient account or  need it to exist on the owner account...or sent to and recorded on both.  

  • 0 $organization in reply to John Trimble

    I admittedly continue to find anything around "extra" email addresses in Tessitura mostly a mystery, but my initial inspection of my own system recently (re CPP planning) has me currently concluding the following:

    • The standard EAddress element for Output Sets looks for a Primary designation; if you want something different, you'll need to do something other than this default.
    • I found one (?) other prebuilt option for Email address, but it was set up similarly.
    • The output set is, at least unless coded very specifically otherwise, always going to look to the constituent record that is returned in the List results. (Technical reminder: a List is really not much more than a set of IDs; it's the Output Set that provides the interesting data.) So, if the email address you want is on a different record, you're going to need something somewhere that repoints the results.

    I've not needed to handle the situation as described, but I do frequently add a "Role =" to criteria for emails for our school programs so quickly realized I had to figure out something after my list count was double what I expected and had a lot of school accounts.

    Shorter: agreeing with John Trimble but explaining differently.