Securing constituent information

I would urge you to discuss these options with some other consortium members here in the community.  I don’t think assigning Constituent Types for each organization is in the consortium’s best interest.  These are intended to be broad categories, classifying the type of constituent (Individual, Organization, etc).  This only becomes more important in v11+ (the introduction of Households).

In addition, I think you are going to find that a lot of constituents in your database in fact frequent performances and/or donate to multiple organizations.  One guideline to keep in mind here is that everything (with the exception of phone numbers unattached to the primary address) on the General tab is visible to ALL users.  This means the default salutation, primary address, primary email (eaddress), etc, cannot be control grouped.  What most consortiums do is construct a second address/eaddress/salutation that IS control grouped to each specific organization.  This is mainly done for patrons with engaged involvement.  The General tab can be edited by all users.  It’s securing the secured address types, eaddress types, and salutation types that prevents friendly fire between organizations.  Beyond that, nearly every facet of a constituent record is easily secured by control group to prevent private data from being shared.

Definitely create separate secured constituencies for each organization, so that you can see a patron’s involvement in broad stroke.  This also helps to administrate the system when it comes to handling merges, as you can at a high level see when a potential duplicate merge may affect more than one organization.  I wouldn’t, however, begin to prevent one organization from accessing a constituent’s record simply because of involvement at another organization.  What if Organization A’s board member came to the box office at Organization B to buy a ticket?  If the box office user can’t access the board member’s record, they’re going to create a new one.  Suddenly the board member has a duplicate account.  Months later, Organization A goes back into the Board member’s constituent record and mistakenly enters a note in the incorrectly created duplicate constituent.  It happens, and this is just one of the scenarios!

I’m sure my fellow consortium advocates will chime in here with some other friendly advice.

Best of luck to you and best wishes on this exciting endeavor/project/trial/journey/party!

-Ryan

PS.  Pleazzze pardon my US-centric zpelling of organization. <sly grin>

From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Mark Ridley
Sent: Wednesday, April 20, 2011 8:27 AM
To: Ryan Creps
Subject: [Tessitura Technical Forum] Securing constituent information

Hi

We are currently in the process of moving from a single organisation setup to a multi-organisation consortium setup, and the timeline for this transition has been tight.

So we haven't had time to consider exactly how we are going to cope with multiple organisations managing customer records in the long term. Also we do not want to make any changes to our existing website as we are currently looking to start the redevelopment of that later this year, when we can incorporate any changes necessary without paying twice for it.

As a short term option, I am looking at doing the following.

• Control Grouping (as much as possible) but in partucular constituencies
• setting up new constituent types for the new org which then point to their own standard address,email address etc (on the General Screen)
• setting lp_customer_rank to add in an organisation specific consituency every time a customer is created (using cust_type to determine which constituency to add)
• setting security such that each organisation can only add new customers or edit customers with one of their constituencies set.

I know this feels over the top and can see that duplicates and merging could be an issue.
I am hoping to implement this only to give us more time to see how the consortium works and come up with better working practices, but mainly to ensure that no violation of data occurs before then.

Will this work? Are there any major issues any one can see by implementing this this way?

Thank you

Mark

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!