Does anyone have any guidance on what are the best practices for emails and contact points / permissions for consortiums? Our member organizations were implemented at different times and are using the Tessitura functionality differently and I'm trying to determine which practices we should standardize on. (Some of the organizations are using contact purposes and/or permissions now and I'm working on setting the others up.) Is it necessary for each organization have it's own control-grouped email type for any of their customers? Should the contact permissions (which are control grouped) be tied to a control-grouped email vs. the non-control grouped one? How should output sets be managed to facilitate the process of each organization pulling emails for their e-news and ticket information (not all of our organizations use WordFly and there are concerns about one organization pulling another's emails). If this has been discussed before or presented at TLCC, I'd love to see that info. If not, is there any interest in discussing this at TLCC?
To be sure, Contact Permissions are not connected to emails (or other Contact Types), but are connected to the constituent instead.
I can't be much help here: we keep our customer accounts separate, so we can leave decisions like this completely up to the consortium members for their org. We are, finally, all using Contact Permissions, though.
Sorry, it should have said "Should the contact purposes (which are control grouped) be tied to a control-grouped email vs. the non-control grouped one?"
Ah, gotcha! Applying all those contact purposes must be a challange.
Carol Keeney & I discussed this a little at TLCC Orlando this month, but I wanted to chime in here in case others had the same question.
Some of this depends on your consortium and how your member organizations have agreed (or not) to share email, but here at the Philadelphia Regional Arts Consortium we do not share email addresses at all. (To get around the Primary email on the General tab, we have a background script that clears the primary indicator from that shared email address and sets the type corresponding to the record creator's control group.)
For contact permissions, we have 3 consortium-wide permissions, and then additional control-grouped permissions for each organization. To help the Consortium staff manage these permissions and provide guidance on list building, we offer the same permissions for each organization:
For contact point purposes, our member organizations have complete flexibility in defining them. (We also offer one "Primary" CPP that mimics the "Primary" checkbox but is applied at the control-group level.) When we first implemented CPPs, we only set the control group if the type was super-specific to one of our organizations and other organizations would just view it as clutter. Our reasoning was that if your email addresses are already using control-grouped types, then it's redundant to have control-grouped CPPS as well. However, it doesn't hurt to have control-grouped CPPs, and we've since realized that it actually makes things easier on everyone if all of the CPPs are consistently control-grouped.
Here's our current setup:
In the above screenshot, each of those Purpose Categories is for a different member organization's control group.
Something to keep in mind, and this applies to postal addresses as well: while different control groups can share an email (or mailing) address and apply their own CPPs to it, they either can't select a salutation type or can only select one that is visible to both control groups. If salutations are important to any of your organizations, you would definitely need to work this out. PRAC's solution to this is already solved by only allow control-grouped email addresses. This does pose a problem for us for mailing addresses, so we have a data standard that states that control-grouped salutations cannot be applied to addresses visible to the entire consortium, and then a script runs overnight and removes any problem salutations from address records.
I did participate in a TLCC presentation on this in 2019 focused around setup and migration to CPPs, and I'm happy to add it to to the documents page for this group, just with the caveat that parts may be out of date or will be with v16.