Hello All,
We recently had a mailing which produced some returned mailing due to “address not found” with no forwarding address.
I’m curious how you handle constituent mailing addresses in the system that do not have a current mailing address after realizing the address on file is invalid.
Our goal is to have no address on constituent records with outdated mailing addresses so they are not accidentally pulled on a list by any other departments.
We just learned that we are unable to delete or inactivate the constituents' mailing address after our conversion from AV years ago placed the phone number with the primary address. An error message appears: Address cannot be inactivated when there is no primary address on file.
Any shared procedures, reports or insights you have is greatly appreciated as we have another mailing coming up soon.
Thank you,
Darnell Graham
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.