Primary Addresses

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.

1024x768 Clean false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

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!

 

 

But that is the issue. What may be the primary for one organization may not be the same for the others. This especially is apparent for corporate records. Each organization could and usually has a different relationship with the corporation where their contact and address could be different. We have one record where each organization's contact are in different states.

---

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.

Please consider the environment before printing this email.
=====This message is intended for the addressee(s) named and may contain confidential information.
If you are not the intended recipient, please delete it and notify the sender.
Views expressed in this email are those of the individual sender and are not necessarily the views of the Sydney Opera House Trust=====

I like a lot of the suggestions about primary by organization, but every road seems to lead back to the central box office conundrum.

To Marty's suggestion that maybe the central box office owns the order, that wouldn't work in our case where if date/performers change/cancel then generally the presenting organization wants to contact the patron, not have the central box office contact them. 

They also want to be able to solicit them for further sales or donations and if they only have access to the name of the patron (assuming they don't have their own controlled address in the system) then they have no way to do that.  

Perhaps this scenario would work if there could be a way that Org B could say 'show me all addresses associated to Perf X' and the system would allow them to see the information based on the fact that their control group has access to that performance, regardless if they see the address in the actual record.  This way they could still include the address in a postal mailing if desired or they could choose to then associate those addresses to their controlled types using a process that would check for potential duplicates within their controlled addresses.  The issue I see with this is what if the patron bought the tickets as a gift and asked that they be shipped to an alternate address that is not theirs.  I guess you could get around that by adding an additional flag on an address that indicates a gift purchase, but this seems to make things even more complicated.

Hi All,

Good day.

personally I like to separate things into pieces, then join them together in the way I want.

first,

the t_address should be a stand alone table with a customer_no as FK and an address_no as PK.

second,

if we need to add some relationships to this address_no, we should do it in another way, which is tx_address way.

third,

if in a consortium, tx_address can let you have your own choice.

so,

it will become clear, t_customer is for customer name and something,

t_address is an address-only table, ok, it should has a FK to t_customer. that is all.

tx_address table is relationship table, you decide what should be put in there.

like holiday address, home address, work address, it is your call.

 

have fun

Ben

 

Frankly reading this thread made my head hurt... loved your Doonesbury reference Nancy!

My thoughts - as related to the new constituent model: Samantha, Tim's wife, has her own constituent number, and she prefers to get old-fashioned mail at their house on Opera Drive. (She likes walking to the mailbox for exercise.) That would be her "primary address"... on the other hand, Tim has his own preferred contact method at his own preferred smartphone number - that combination becomes his "primary address" ...

I have to give my zip code to the gas station in Illinois in order for my credit card to be charged. We will have to have zip codes for purchasers wishing to use their credit cards with us, even if Tim only wants us to "correspond" with his smartphone. When Tim shows up at the Box Office for an upgrade or whatever - the chance that he will in the very near/near/far future NOT have a physical ticket present is increasing.

What about this idea of two segments of patrons - 1) purchasers/those wishing to make their first purchase, and 2) not yet purchasers. If you are in the first segment, you MUST HAVE an address. If we define address as "Smartphone number plus postal zip code" - fine. That becomes "primary" - even though it isn't a physical structure. And, for orgs to which this change comes more slowly (i.e. not going to use smartphone ticketing in the very near/near/far future) - they can still have a primary address and set up their own rules about how it gets used. 

As for segment #2... the idea with them would be to make corresponding with our organizations "barrier free"... so if they don't want to give us their address at that stage of our "relationship" - fine. I think.

And overall, I do think that you have to have some really obvious simple "no brainer" way to eliminate duplicates from old-fashioned Postal Service-style mailings. Primary address does that for us now, but I think that if we put the brochure in the mail to Samantha, and Tim gets the same info sent to his smartphone - that's a win.

We definitely need a unique identifier of some kind to come up in the initial consituent search. 

eg Ticket seller is on the phone to customer, Sally Brown.  He types her name into the constituent search - twenty records come up.  Currently, he identifies the correct record by address.  If this is not available, he would need to identify by phone number or email.  Otherwise the operator will be creating Sally Brown record no. 21.

This is a problem for everyone but is exaccerbated in the consortium environment because of the sheer potential for duplication.

Another thought on this:

It would be good for each organisation to be able to specify which fields should be mandatory when a record is created.  We could then ensure that some kind of contact information is captured - either address OR phone OR email.

(Sorry - can't think of a coherent way to turn this into a story.)