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!

Mark,

Welcome to the consortium world!

We are an consortium with a total of 4 organizations. We only use control groups for security. With that being said, all organizations use the same customer records but with control groups, the organization can only see their data plus the "Primary" data such as the primary address, salutation, and other non-control group information. This kind of information is usually found on the general tab. In general, all organizations will have access to all customer records even though you could filter by constituencies but they could just turn the filter off. I don't believe that you can prevent that functionally.

We have found only a couple minor issues with the current set up and for the most part been able to overcome this.

First. A certain customer may be a VIP to an organization but a different organization is capable of changing the primary address. This would tend to upset the organization that has them as a VIP. What we do is put an icon in the constituent header stating that this record is a VIP of an organization. This means that we must first contact that organization stating that there is a change and they have the option of approving the change.

Second. Corporations... One organization may a contact to the corporation that is different than another organization. We decided to overcome this with putting the name of the senior officer as the primary name but use control grouped salutations and addresses for each organization. Another method would be to use associations.

All in all, 99% of the data is secure by organizational control grouping, you just need an agreement between all organizations on how to handle primary non-control group data.  

Feel free to contact me if you have any questions on our set up. I would be happy to help.

Marty Jones

Director of Information Services

Omaha Performing Arts
1200 Douglas Street

Omaha, Nebraska 68102

P 402.661.8469

Marty.Jones@omahaperformingarts.org

www.omahaperformingarts.org

For tickets, call Ticket Omaha at 402.345.0606

From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Mark Ridley
Sent: Wednesday, April 20, 2011 7:29 AM
To: Martin A. Jones
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!

I knew you would get some spirited replies.  Thanks, Levi and Marty!

J

It’s a short ways off (about 87 days and fast approaching!), but there is a TLCC2011 conference discussion session on Constituent Records in a Consortium, which I and Kim Lee from the Sydney Opera House consortium will be hosting.  The tagline of course is “Hey that’s MY customer!”.   This and similar topics always prove to be a lively discussion.