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.

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.