Is there a way to "inactivate" a primary address? We have mail come back due to bad addresses. Because the system requires a primary address, is there a way to inactivate it so we do not continue to pull an incorrect address into lists? If not, how do others handle this problem? Thank you!
Submit an enhancement request! We decided to work around this issue by using an address purpose to "flag" an address as needing deactivation, and then doing it directly with a database script. It's only the tessitura desktop client that disallows single-address inactivation.
Like Nick we also have a few different address purpose flags - one for returned mail with bad addresses and a few others flagged in our monthly NCOA. You can then use those as exclusions in your list extractions. One word of caution is to train your front end users when they correct or change addreseses to double check if there is a bad address flag and remove it otherwise you'll forever be suppressing them from mailings.
Hey Denise,
Actually, as of version 11, a new field was added in T_DEFAULTS called "require address". The default is set to yes but you can change it to no. Doing so allows you to create accounts without a primary address. I did this when I worked at John Michael Kohler Arts Center in Sheboygan, WI. As a museum, they wanted to be able to capture patron information, and we found that patrons were more willing to give an email address versus their whole address. So we changed the default setting.
Here is the help link: http://www.tessituranetwork.com/Help_System_v125/Tessitura_v125_Left.htm#CSHID=System_Tables|StartTopic=Content%2FSystem_Tables%2FSystem%20Tables.htm|SkinName=TN Skin
Christopher Cuhel, The 5th Avenue Theatre
Concurrently...what many organizations do is create a suppression set in extraction manager to supress anyone out with a bad address flag. We also have our headers set here at The 5th to populate a field saying "bad address" so that our guest services team knows to ask to change it. I believe that was some custom work we had done long ago for a custom header for our guest services team.
Our work-around has been working really well for us!
When we realize an address in Tessitura is incorrect, we update the primary address to read:Needs AddressAustin, TX 99999
The "Needs Address" is an easy visual flag for users to update addresses whenever pulling up an account for any transactions. And the "99999" zipcode is an easy suppression in Extraction Manager.
Greg GarciaZACH TheatreSenior Ticketing Services Manager
We use the 9999 Unknown framework and bad address types too. I run the Manage Attribute utility nightly as a scheduled job to update anyone with an unknown or bad address to have a control-grouped Invalid Address attribute, which makes suppression in list manager a piece of cake. Every so often, I'll review the patrons with the Invalid Address attrbute to see if it should be removed (someone else in the consortium updated the address or our staff forgot to remove it when updating the address).
We require address as well, and decided to create an 'Invalid Mailing Address' address type that we use and the suppress this address type from any mailings. Reps are to look for this when speaking to patrons, update the address and then change the address type back to Home or Business address type.
We change the Address type to 'Returned Post' and suppress those from our mailing extractions.
Kelly
We do a combination of things. We have a few different address types depending on the situation (Incomplete Info, Moved, and Returned Mail). These address types trigger an icon to display on our constituent header so that our staff are alerted to update the address if possible when speaking to the customer.
On Street 1 for these addresses we preface what we have (if anything) with 000 so that we can sort by street 1 and remove those addresses before mailing. If we don't have city or postal code we also use 00000 in those fields. As the address becomes complete or up to date the staff remove all of the 000s so that the address is usable.