Hi
We have made the business decision to no longer require a physical address to create a constituent record - we anticipate this will encourage more sign ups for free events if all you need to give us is an email and not your home address and phone number (we will still require an address for ticket purchases and donations).
If you have done this as well, I would love to hear from you to pick your brain about best practices for instituting this change. A few things that I have been thinking about:
1. Should we make accomplish this by blanket making addresses not required by setting the default to No for Require Address in T_DEFAULTS or should we take advantage of the default street1 and default postal code settings for the web in T_DEFAULTS thereby still technically requiring an address, just not from the patron?
2. How are you prompting patrons to give you an address if they are making a purchase? On the payment page? In the cart? Somewhere else?
3. Did you run into any unexpected issues?
Any insight would be appreciated! It seems really easy to make the change from a technical standpoint but I am concerned I am missing something process wise.
ThanksJess LevySan Francisco Opera415-551-6319
I’m very much a fan of setting Require Address to No in T_DEFAULTS. Using a dummy default address to me just feels like adding wrong data to your database, when NULL is a perfectly accurate representation of when the address for a customer is unknown. If you want to ensure addresses for a certain class of constituent, this can be instituted as a data quality reporting process, like a set of list criteria whose results are surfaced to a data manager.
The only potential technical issues issues you face from making this change would be bugs in Tessitura or customizations that (incorrectly) assume each constituent must have an address. For example, a custom report procedure could be doing an inner join between T_CUSTOMER and T_ADDRESS (or an equivalent function or view) instead of a left join, causing customers with no address record to be filtered out of the selection when there was no intention for that join to act as a filter. Or, after left joining T_ADDRESS, A procedure might not account for the possibility that joined columns could have a null value.
So, if you have any custom reports or procedures, definitely do your due diligence either by testing their accuracy when working with address-less constituents in scope, and/or doing a code review for the anti-patterns I mentioned in procedures that handle address data.
Nicholas Reigle,
I think I have most of the requirements turned off. However, I don’t seem to be able to create an account without a dummy salutation. Even though I might only have an email address. Do you know what the least requirement is when one only has an email address?