One of our assumptions has been around the idea that a Next Generation constituent needn't necessarily have a postal address. As many of you know this requirement in the current software has caused us to jump through some hoops with web registrations where we actually temporarily create constituents with a dummy address. So the thought was if a large percentage of your constituents only address you electronically, why bother with a required postal address? Furthermore, considering the type of "groups with members" constituent model that we've been talking about, why should a every child in a family need an address when all of the children belong to a family that has a postal address?
So yesterday we got into having a big discussion about whether we needed to carry on the notion of a "primary address" for a constituent. Currently each constituent must have a primary address and that primary address must not be control grouped--everyone can see it.
Primary addresses has some nice advantages--if you want to analyze purchasing by postal code sometimes you just need any easy way to get to a postal code. Plus if you've got several addresses on a constituent and none of them really match the criteria for a particular mailing, you've always got the primary address to fall back on.
Obviously if no postal address is required then you can't force a primary address. You could make a rule like "if there are any addresses, then one of them must be primary". But then we thought, "does this work in a consortium setting"? Let's say the Symphony and the Ballet share a system. Couldn't you make the case that the Symphony might want to store a private address that only the Symphony could see? And that's the only address the constituent has on file? You can't say it's the primary address because the Ballet can't see it.
So several questions:
1. What about this notion of a constituent with no postal address? Does that make sense? Or does the current model feel better? Even with the group/member model we could say that each constituent has to have a primary address, even if that address is not specifically tied to that constituent. That's the example of the child's primary address actually being the family's address.
2. If there were no requirement for a postal address, then there are obviously still times when one is required. We couldn't have a delivery method of "Mail" if the constituent didn't have an address. Of course we could require that an order have a shipping address before allowing that delivery method. But what does this do to subscribers if some percentage of subscribers didn't have postal addresses? Or is this just the way the world is going and we have to learn to operate that way?
3. If we don't require an address, what about a primary flag? Is it ok for a constituent to have say 3 addresses (some shared, some not) and none of them being a primary address? Is it ok for a constituent to have 3 addresses, all only visible for some part of a consortium?
Believe me it's a nice feeling knowing that we can put questions like this in front a large, interested audience. We're eagerly awaiting your help.
Could you allow us to have a primary address by organization? So if I have three members of our consortium, it could be possible to have up to 3 different primary addresses?
Marty
Ok, say you have three organizations each with their own primary address. Then you have a central box office that can see all addresses. So they see three primary addresses. All of sudden, primary doesn't seem primary any more. That's the dilemma that I keep bumping up against.
And that would be the issue we would face since we do have a central box office. We would almost need to treat the central box office as it's own entity. In our case, if our central box sells a ticket to a show, they manage that order. Even though the ticket may be to my performance that I am presenting, I do not have access to the order but I do have the capability to report on the sale.
Therefore it would make since that the box office would need to have their own default addresses. Maybe these addresses can be seen by all or maybe just by the central box office. It's a coin toss for me.
If I had a "Private Address", In our current system, I would set up each organization with a minimum of two control groups. One where all of the seasons get set up that the central box office has access to all of them but the other control group would be for the organization only and this is where I would put the "Private Address" and the central box office and everybody else can not see.
Thanks,
For what it's worth, I think my preference is for the concept that if address is optional, primary address is also optional. So one consortium organization could have a private address that is not shared without having to create a primary and shared address.
I also like the idea that, although a primary address isn't required, a record can only have one primary address, and that address has to be public or shared. I think that this restriction provides some simplicity in selecting a default address for list pulls, ticket mailings, etc. without requiring users to enter a bunch of complex rules about which primary address to use under which circumstances.
But that assumes that the “primary” is different for each organization. Won’t the primary contact given by a constituent usually be the same given to each member of the consortium?.
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif Sent: Wednesday, February 24, 2010 2:57 PM To: rbernard@smm.org Subject: Re: [Tessitura Next Generation Forum] RE: RE: Primary Addresses
From: Marty Jones <bounce-martyjones7649@tessituranetwork.com> Sent: 2/24/2010 2:49:36 PM
You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!
Spam Not spam Forget previous vote
Musing here....
I tend to agree with Marty here, that it's too much to ask for a centralized box office to deal with multiple primary addresses. In addition, their mailing process would have to have some way of prioritizing "which primary is primary" on a record.
My thought on this is that the primary flag is really only visible to an organization. Since a user group has only one organization defined (in the current paradigm with TR_ORGANIZATION), would it be better if only the current organization's designation of primary was seen? A three organization consortium could, for example, have a constituent with three separate addresses, all visible, but each would have their own primary flag on a different address. Or, each organization could flag the same address. The primary flag visibility is determined by which organization you represent in your user group.
If an organization wishes the control group an address and mark it primary, this concept I believe would hold true except in circumstances where usergroups within an organization could not view an address according to control group security. To illustrate:
Consortium: Opera, Symphony; control group of "Opera Development" is only visible to Opera Development users
Constituent Mr Smith has one address, marked as "Opera Development" type, secured by Opera Development control group, and marked primary.
Symphony View: Mr Smith has no addresses on record.
Opera Development View: Mr Smith has one address on record marked primary and of type "Opera Development".
Opera Ticketing View: Mr Smith has no address on record.
The last "view" here is a problem, as theoretically, any mailing done by the Opera should pick up the primary address on Mr Smith's account. If an Opera Ticketing user is running the mailing process, this address is not visible.
Furthermore, what happens if the Opera Ticketing user adds a new address and marks the address as primary (to Opera). What then happens to the Opera Development address still marked primary, but not visible to the ticketing user?
Couple of options:
1. Automatically move the primary flag for the Opera from the Opera Development address to the new address. (probably not the best answer!)
2. Require that addresses marked as primary be visible to every user in at least the organization.
a. Does this override the control group? Defeats the rules for control groups...
b. Does this create a "sync'd" copy? Unnecessary overhead, duplication.
c. Does it force a control group change to a control group that ensures visibility to the entire Opera organization? Intriguing in my opinion, but not feasible to do it "automagically".
What if we stepped back and at the time of address creation allowed a control grouped address type, but required that the assigned control group would keep the address visible to users in a single organization? So, in the example above, the Opera Development user when creating Mr Smith's address could create a new address, but could only assign a type of "Opera", instead of "Opera Development", as Opera Development would imply that Opera users outside of opera development couldn't see their primary address.
My thoughts, anyway!
From: Marty Jones <bounce-martyjones7649@tessituranetwork.com>Sent: 2/24/2010 3:35:19 PM