Constitutent Outdated Address Removal

Hi Darnell,

We use the Address Type of Inactive Mailing Address and use this to exclude from mailings. The trick is to ensure that once the address gets updated to ensure that your staff are changing the address type back to Home or Business address. We also keep an up to date list manager list of active files with inactive mailing address type and staff will go through this list as time permits to check for updates.

Michele

We do it a little differently, we use a Bad Address CSI to track these patrons. We can exclude anyone wtih that CSI from mailing list. Also, by using the CSI we have a little icon on the patron's header that alerts us to the fact that we don't have a current address for them. The CSI are added by our data entry clerk or the box office when we get mail back or information from the mail house.

Once we have a new address, we add it and close the CSI. The problem is getting people to close the CSI, so I'm working on a way to audit changes and make sure they get closed.

Overall, we don't remove addresses, just mark them former/inactive and leave them on the record once we get a new one.

Here at The 5th Avenue Theatre, we use the mail restriction with a drop selection of "check address". We do this similarly with phone and email. We have some custom work done that populates "check address" into the header so should that patron call, our sales agents are prompted to get a new address. The custom work to populate the header with this information pre-dates my time here at The 5th sadly. Without custom work, you could also create a constituency that is for a bad address. That three letter/character code will appear in the header as a prompt for sales agents to get a new address.

Either way, you can use the constituency or the mail restrictions information as a suppression set in an extraction so bad addresses don't get pulled into lists. Also, you could pull those names as a separate list for your NCOA updates and try to get current address information for bad accounts.

Chris Cuhel

The 5th Avenue Theatre

My way of attending to this same problem has been to go over the application logic's head. That is, the Client application does not want you to inactivate an address when it is the current primary address. I consider this to be a bug -- you can set Tessitura to accept records with no address, and in reality this is exactly what these "no forwarding address" records should become. So the application is needlessly restricting you from inactivating the last active address on a constituent record.

I tried the strategy of using an "Inactive Address" address type for some time, but found this unsatisfactory because operators have to be very dilligent in checking address types when doing list output sets or even just browsing the application. What I really want is for the address to show up as inactive, so that Tessitura knows what to do with it.

Turns out that if you inactivate the address on the database side such that a constituent record has one or more addresses that are all inactive, the client application behaves exactly as it should. And as a matter of fact, the built-in record merge procedure can result in this exact same constituent state if you happen to merge a constituent with an address into a constituent with no address. So all I needed to do was come up with a workaround for getting these address records marked as inactive.

I decided to do this by using a contact point purpose as a flag to a SQL agent job. If I have an address on a constituent record that needs to be inactivated (but can't because the client is complaining that it's the primary address), I assign it the "Inactivate This Address" contact point purpose, and then on a nightly basis a script runs that inactivates the address, removes the primary indicator (or reassigns it if there are other active addresses), and finally removes the "Inactive This Address" purpose.