Storage of Email, Contact Restrictions, Phone - Consortium

We are in the process of forming a consortium with our organization as the master license holder utilizing our existing DB. Prior to completing a consortium merge, I need to move our organization's email addresses and contact restrictions from 'Other' in the General Tab to secure the data.  I think we should look at moving the phone numbers as well.  I've been advised to move these to Attributes but I understand that this could create issues as the email addresses will not be stored where they were intended within the Tessitura structure and this could create the need for additional workarounds.  I also need to consider how this will impact suppression lists, etc.  The intent is to keep the data for each organization separate and secure. I understand that control groups are not an option for any data on the General Tab.  I'm interested to hear how other consortia have address these challenges.  I'm also interested to hear how other consortia have handled merges given the fact that data should be kept separate and secure.

Thank you,

Shereen 

Parents
  • Hello Ken,

     

    Thank you so much for your response.  This is very helpful.  I have a follow up question regarding the control grouped data and merges.  If the only criteria available for merge is name and address as everything else if control grouped, how does the merge affect the control grouped data or is it affected at all?

     

    Shereen

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Ken McSwain
    Sent: Wednesday, May 29, 2013 8:08 PM
    To: Shereen Marino
    Subject: Re: [Tessitura Technical Forum] Storage of Email, Contact Restrictions, Phone - Consortium

     

    Hi Shereen

    I think you need to look at each of those things individually.

    • I would definitely move your contact restrictions to attributes. The three settings on the general tab don't work at all for consortia - we have them locked off, effectively - the only valid value is (none) [except for one consortium member who uses POP's generic Express website, which insists on setting the general tab value - but to deal with that case we have a utility script which runs overnight and moves them to an attribute]. Each consortium member then has their own set of attributes for handling contact restrictions related to them. And then you'll need to update all of your standard suppressions, of course, as you say.

     

    • To deal with the email addresses, I certainly wouldn't move them to Attributes - you need them to be emails. That's where you need to use control-grouped Types to control access. Maybe like this:
    1. Create a new email Type which is Default control grouped, and make that the default (you need one of those, particularly for web registrations, which have to use a non-control-grouped email Type, because it is made Primary by default)
    2. Use a script to make all of your existing emails non-primary. (That will remove them from the General Tab, and make it possible to control-group them)
    3. Control-group your existing email Type, and re-name it to something that indicates it belongs to you - In our consortium we use a set of tags for consortium members which are prefixed to any control-groupable Types , so that, for example, an email type called "ACO Main" belongs to us, one called "OA Email" would belong to the Opera, and one called "UCSS Email" would indicate that it's shared across the whole (UCSS) consortium .
    • Phone numbers are different, of course, if you've used the "Fixed Line" numbers, which are attached to addresses. If you really want to hide them as well, you'd have to hide their linked addresses too. I think I'd just be creating new control-grouped Phone Types,  converting your existing numbers to them, and removing the address links,. In that case, you'd lose the link to the specific address, of course, but unless you want to start duplicating primary addresses into control-grouped ones, and then removing the phone numbers from the primaries, which sounds a bit fiddly, that might be the best option. 
    • OTOH, we've always treated fixed line numbers on the Primary address as shared data. If they're particularly sensitive, you can always put them on a control-grouped address or  phone type, but it doesn't seem to be worth hiding something that can be picked up from a phone book or other public domain source.

    Ken

    From: Shereen Marino <bounce-shereenmarino5792@tessituranetwork.com>
    Sent: 5/29/2013 12:50:58 PM

    We are in the process of forming a consortium with our organization as the master license holder utilizing our existing DB. Prior to completing a consortium merge, I need to move our organization's email addresses and contact restrictions from 'Other' in the General Tab to secure the data.  I think we should look at moving the phone numbers as well.  I've been advised to move these to Attributes but I understand that this could create issues as the email addresses will not be stored where they were intended within the Tessitura structure and this could create the need for additional workarounds.  I also need to consider how this will impact suppression lists, etc.  The intent is to keep the data for each organization separate and secure. I understand that control groups are not an option for any data on the General Tab.  I'm interested to hear how other consortia have address these challenges.  I'm also interested to hear how other consortia have handled merges given the fact that data should be kept separate and secure.

    Thank you,

    Shereen 




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

    Shereen Marino | Data Analysis Manager | (602) 452-0414: Office |
    The Phoenix Symphony | 1 N. 1st Street, Ste 200, Phoenix, AZ 85004 | www.phoenixsymphony.org

    The Phoenix Symphony Salute to the Troops

    May 31, 2013 | 8:00pm | Symphony Hall
    June 1, 2013 | 8:00pm | Symphony Hall
    June 2, 2013 | 2:00pm | Symphony Hall

    Join Maestro Chafetz and The Phoenix Symphony and Chorus to celebrate freedom with a repertoire of patriotic favorites from John Philip Sousa, John Williams and more. Active servicemen and Veterans are encouraged to attend in uniform.

Reply
  • Hello Ken,

     

    Thank you so much for your response.  This is very helpful.  I have a follow up question regarding the control grouped data and merges.  If the only criteria available for merge is name and address as everything else if control grouped, how does the merge affect the control grouped data or is it affected at all?

     

    Shereen

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Ken McSwain
    Sent: Wednesday, May 29, 2013 8:08 PM
    To: Shereen Marino
    Subject: Re: [Tessitura Technical Forum] Storage of Email, Contact Restrictions, Phone - Consortium

     

    Hi Shereen

    I think you need to look at each of those things individually.

    • I would definitely move your contact restrictions to attributes. The three settings on the general tab don't work at all for consortia - we have them locked off, effectively - the only valid value is (none) [except for one consortium member who uses POP's generic Express website, which insists on setting the general tab value - but to deal with that case we have a utility script which runs overnight and moves them to an attribute]. Each consortium member then has their own set of attributes for handling contact restrictions related to them. And then you'll need to update all of your standard suppressions, of course, as you say.

     

    • To deal with the email addresses, I certainly wouldn't move them to Attributes - you need them to be emails. That's where you need to use control-grouped Types to control access. Maybe like this:
    1. Create a new email Type which is Default control grouped, and make that the default (you need one of those, particularly for web registrations, which have to use a non-control-grouped email Type, because it is made Primary by default)
    2. Use a script to make all of your existing emails non-primary. (That will remove them from the General Tab, and make it possible to control-group them)
    3. Control-group your existing email Type, and re-name it to something that indicates it belongs to you - In our consortium we use a set of tags for consortium members which are prefixed to any control-groupable Types , so that, for example, an email type called "ACO Main" belongs to us, one called "OA Email" would belong to the Opera, and one called "UCSS Email" would indicate that it's shared across the whole (UCSS) consortium .
    • Phone numbers are different, of course, if you've used the "Fixed Line" numbers, which are attached to addresses. If you really want to hide them as well, you'd have to hide their linked addresses too. I think I'd just be creating new control-grouped Phone Types,  converting your existing numbers to them, and removing the address links,. In that case, you'd lose the link to the specific address, of course, but unless you want to start duplicating primary addresses into control-grouped ones, and then removing the phone numbers from the primaries, which sounds a bit fiddly, that might be the best option. 
    • OTOH, we've always treated fixed line numbers on the Primary address as shared data. If they're particularly sensitive, you can always put them on a control-grouped address or  phone type, but it doesn't seem to be worth hiding something that can be picked up from a phone book or other public domain source.

    Ken

    From: Shereen Marino <bounce-shereenmarino5792@tessituranetwork.com>
    Sent: 5/29/2013 12:50:58 PM

    We are in the process of forming a consortium with our organization as the master license holder utilizing our existing DB. Prior to completing a consortium merge, I need to move our organization's email addresses and contact restrictions from 'Other' in the General Tab to secure the data.  I think we should look at moving the phone numbers as well.  I've been advised to move these to Attributes but I understand that this could create issues as the email addresses will not be stored where they were intended within the Tessitura structure and this could create the need for additional workarounds.  I also need to consider how this will impact suppression lists, etc.  The intent is to keep the data for each organization separate and secure. I understand that control groups are not an option for any data on the General Tab.  I'm interested to hear how other consortia have address these challenges.  I'm also interested to hear how other consortia have handled merges given the fact that data should be kept separate and secure.

    Thank you,

    Shereen 




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

    Shereen Marino | Data Analysis Manager | (602) 452-0414: Office |
    The Phoenix Symphony | 1 N. 1st Street, Ste 200, Phoenix, AZ 85004 | www.phoenixsymphony.org

    The Phoenix Symphony Salute to the Troops

    May 31, 2013 | 8:00pm | Symphony Hall
    June 1, 2013 | 8:00pm | Symphony Hall
    June 2, 2013 | 2:00pm | Symphony Hall

    Join Maestro Chafetz and The Phoenix Symphony and Chorus to celebrate freedom with a repertoire of patriotic favorites from John Philip Sousa, John Williams and more. Active servicemen and Veterans are encouraged to attend in uniform.

Children
  • Former Member
    Former Member $organization in reply to Shereen Marino

    Hi Shereen

    The backend components of the merge process [Identify dupes; merge validation; and the actual merge process itself] are all unaware of control-grouping.  They see everything, and merge everything, ignoring the control group restrictions.

    in terms of your own users making decisions about whether to schedule two constituents to merge, and which direction, they can only see shared data plus data for their own org, which raises the level of difficulty a few points. That's one reason why we customised our merge validation script to try to make sure that merges follow our collective business rules, and block merges between two high-touch constituent records for referral to the consortium support team. They can see everything, and can then check that the merge is ok with all relevant orgs before approving it.

     

    Ken