Storage of Email, Contact Restrictions, Phone - Consortium

Hello Ken,

I’m working through the phone numbers now.  When you say the addresses are attached to the phone numbers, are you referring to the column address_no in T_PHONE – is this how they are linked?  How should the “link” be removed? 

I’ve created control grouped types for phone numbers and as you mentioned “moving” the numbers is really a matter of changing the column ‘type’ in T_PHONE as opposed to moving the numbers.  I’m working on this in Test prior to moving it to Live.  I’ve been able to change the bulk of the number types to place them in the proper control grouped type for each organization.  There’s a sub group that I’ll need to address separately as the script I created is not working for this sub group.  It’s my understanding that moving the phone numbers to the control grouped types would make them invisible to the other organizations but in Test we’ve found this is not the case.  Does this need to be addressed in security or is there something else I’m missing?

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

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!

Hello Ken,

I’m working through the phone numbers now.  When you say the addresses are attached to the phone numbers, are you referring to the column address_no in T_PHONE – is this how they are linked?  How should the “link” be removed? 

I’ve created control grouped types for phone numbers and as you mentioned “moving” the numbers is really a matter of changing the column ‘type’ in T_PHONE as opposed to moving the numbers.  I’m working on this in Test prior to moving it to Live.  I’ve been able to change the bulk of the number types to place them in the proper control grouped type for each organization.  There’s a sub group that I’ll need to address separately as the script I created is not working for this sub group.  It’s my understanding that moving the phone numbers to the control grouped types would make them invisible to the other organizations but in Test we’ve found this is not the case.  Does this need to be addressed in security or is there something else I’m missing?

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

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!