• Replies 29 replies
  • Subscribers 360 subscribers
  • Views 185 views
  • Users 0 members are here
Related

Constituency Based Security

Chuck Reif
$organization

When we originally designed and wrote Tessitura, there were some pieces of functionality that made their way into the system that I never really thought were fully formed or thought out.  As a result these features tend to get very little use or confuse many users.

One such feature is constituency-based security.  This feature allows you to define rights to one or more constituent functions (i.e. editing addresses) based on the highest ranking constituency of that constituent.

Development stories concerning constituencies are starting to come into view and we need to explore whether this security paradigm is worth continuing.

In my opinion, the whole idea of constituency-based security loses a bit of its shine as soon as you realize that it's all based on the highest ranking constituency only.  In addition, the concept was put in place well before Control Groups was ever thought of and we might have thought twice about it if Control Groups were in the original plan.  It's not that Control Group functionality replaces constituency-based security, but rather that sometimes you have to step back and wonder whether there aren't too many layers of complexity.  Especially if one of those layers is not often used--a survey of Network implementation consultants seemed to show that very few sites ever implement this functionality, at least initially.

Another factor prompting this thread is that several times our internal discussion on on how we might better use constituencies going forward has been hampered when someone says "yeah, but don't forget about constituencies and security".

We've tried to model out what would happen if we changed the model so that security could be based on "any" constituency instead of "highest ranking" constituency.  But that always creates problems.  What if a constituent has both constituency 1 and constituency 2.  Constituency 1 says they're allowed to edit addresses and constituency 2 says that they are not.  What to do then?

So some help here, please.  How many sites use this functionality now and how passionate about it are you?

As always, thanks in advance for the feedback!

  • $organization

    I'm not familiar with how constituency-based security works, and it sounds like that may be the case for others as well. Could you give an overview of what exactly it does? It sounds like it's meant to limit what a member of the public can do with their own record based on the constituencies they've been assigned. Is that correct? And how does that interface with control groups?

       -Morgan

  • Former Member
    Former Member $organization in reply to Morgan L'Argent (Past Member)

    Hi-

    We actually use this for a very specific business use. Because we sell youth classes, and we create a child record type which is tied to a parent who might have the same name, we added in a “KID” constituency to those child records and set-up security so that different user groups can’t sell tickets/membership to that record, but still allows them to update address information or do other management of the record.

     

    Thanks

     

    Jeanette Boudjouk

    Database Analyst

    Science Museum of Minnesota

    651-265-9846

    jboudjouk@smm.org

     

     

    Omnifest 2010 brings five giant screen films to the Omnitheater for six short weeks from January 29 through March 11. Members see it free! View this year's films and trailers at www.smm.org/omnifest.

    The Dead Sea Scrolls: Words That Changed the World exhibition opens March 12. Witness authentic 2,000-year-old manuscripts, including the earliest biblical writings. Spiritually significant. Scientifically stunning. Visit www.smm.org/scrolls.

     

     

     

     

     

    From: Chuck Reif <bounce-chuckreif3941@tessituranetwork.com>
    Sent: 2/18/2010 1:37:18 PM

    When we originally designed and wrote Tessitura, there were some pieces of functionality that made their way into the system that I never really thought were fully formed or thought out.  As a result these features tend to get very little use or confuse many users.

    One such feature is constituency-based security.  This feature allows you to define rights to one or more constituent functions (i.e. editing addresses) based on the highest ranking constituency of that constituent.

    Development stories concerning constituencies are starting to come into view and we need to explore whether this security paradigm is worth continuing.

    In my opinion, the whole idea of constituency-based security loses a bit of its shine as soon as you realize that it's all based on the highest ranking constituency only.  In addition, the concept was put in place well before Control Groups was ever thought of and we might have thought twice about it if Control Groups were in the original plan.  It's not that Control Group functionality replaces constituency-based security, but rather that sometimes you have to step back and wonder whether there aren't too many layers of complexity.  Especially if one of those layers is not often used--a survey of Network implementation consultants seemed to show that very few sites ever implement this functionality, at least initially.

    Another factor prompting this thread is that several times our internal discussion on on how we might better use constituencies going forward has been hampered when someone says "yeah, but don't forget about constituencies and security".

    We've tried to model out what would happen if we changed the model so that security could be based on "any" constituency instead of "highest ranking" constituency.  But that always creates problems.  What if a constituent has both constituency 1 and constituency 2.  Constituency 1 says they're allowed to edit addresses and constituency 2 says that they are not.  What to do then?

    So some help here, please.  How many sites use this functionality now and how passionate about it are you?

    As always, thanks in advance for the feedback!




    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!

  • $organization

    We could live without it here at Steppenwolf Theatre. 

    The one instance we did use constituency security in the past was limiting box office staff from editing addresses on accounts with the Trustee constituency.  To be honest though, these finer details become very difficult to maintain over the years.  We've since abandoned it.

    I think shortly after our Tessitura conversion there was a paranoia that different departments would "mess up" the accounts of another.  Thus constituency control seemed like a solution.  But really nothing should replace good cross-department coordination, good training and QC to address those kinds of concerns. 

    That's our experience at least.

     

  • $organization in reply to Morgan L'Argent (Past Member)

    Never mind. From these other responces, I understand how it work now.

    Perhaps functionality could be improved by having the permissions be additive, rather than using only the highest ranking constituency.

       -Morgan

  • $organization

    The National Ballet of Canada does not currently use this functionality.

    In fact, as far as I’m aware, we’ve never used it. All of our security controls and editing rights are based on User Groups.

     

     

    From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif
    Sent: Thursday, February 18, 2010 2:42 PM
    To: Leah Heidenheim
    Subject: [Tessitura Next Generation Forum] Constituency Based Security

     

    When we originally designed and wrote Tessitura, there were some pieces of functionality that made their way into the system that I never really thought were fully formed or thought out.  As a result these features tend to get very little use or confuse many users.

    One such feature is constituency-based security.  This feature allows you to define rights to one or more constituent functions (i.e. editing addresses) based on the highest ranking constituency of that constituent.

    Development stories concerning constituencies are starting to come into view and we need to explore whether this security paradigm is worth continuing.

    In my opinion, the whole idea of constituency-based security loses a bit of its shine as soon as you realize that it's all based on the highest ranking constituency only.  In addition, the concept was put in place well before Control Groups was ever thought of and we might have thought twice about it if Control Groups were in the original plan.  It's not that Control Group functionality replaces constituency-based security, but rather that sometimes you have to step back and wonder whether there aren't too many layers of complexity.  Especially if one of those layers is not often used--a survey of Network implementation consultants seemed to show that very few sites ever implement this functionality, at least initially.

    Another factor prompting this thread is that several times our internal discussion on on how we might better use constituencies going forward has been hampered when someone says "yeah, but don't forget about constituencies and security".

    We've tried to model out what would happen if we changed the model so that security could be based on "any" constituency instead of "highest ranking" constituency.  But that always creates problems.  What if a constituent has both constituency 1 and constituency 2.  Constituency 1 says they're allowed to edit addresses and constituency 2 says that they are not.  What to do then?

    So some help here, please.  How many sites use this functionality now and how passionate about it are you?

    As always, thanks in advance for the feedback!




    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!

  • $organization

    Chuck,

     

    Thanks for asking.  Here at CTG we don’t use them.  As one of our Tessitura users put it, “I am sure we could think of some creative ways to use it…”

     

    Doesn’t sound like it would add a lot of functionality.  I could see where it might be useful but the feature would have to be additive for it to work right in our environment.

     

    Thanks,

     

    Dave

     

    From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif
    Sent: Thursday, February 18, 2010 11:42 AM
    To: Dave Alton
    Subject: [Tessitura Next Generation Forum] Constituency Based Security

     

    When we originally designed and wrote Tessitura, there were some pieces of functionality that made their way into the system that I never really thought were fully formed or thought out.  As a result these features tend to get very little use or confuse many users.

    One such feature is constituency-based security.  This feature allows you to define rights to one or more constituent functions (i.e. editing addresses) based on the highest ranking constituency of that constituent.

    Development stories concerning constituencies are starting to come into view and we need to explore whether this security paradigm is worth continuing.

    In my opinion, the whole idea of constituency-based security loses a bit of its shine as soon as you realize that it's all based on the highest ranking constituency only.  In addition, the concept was put in place well before Control Groups was ever thought of and we might have thought twice about it if Control Groups were in the original plan.  It's not that Control Group functionality replaces constituency-based security, but rather that sometimes you have to step back and wonder whether there aren't too many layers of complexity.  Especially if one of those layers is not often used--a survey of Network implementation consultants seemed to show that very few sites ever implement this functionality, at least initially.

    Another factor prompting this thread is that several times our internal discussion on on how we might better use constituencies going forward has been hampered when someone says "yeah, but don't forget about constituencies and security".

    We've tried to model out what would happen if we changed the model so that security could be based on "any" constituency instead of "highest ranking" constituency.  But that always creates problems.  What if a constituent has both constituency 1 and constituency 2.  Constituency 1 says they're allowed to edit addresses and constituency 2 says that they are not.  What to do then?

    So some help here, please.  How many sites use this functionality now and how passionate about it are you?

    As always, thanks in advance for the feedback!




    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!

  • $organization

    Chuck – We do use it here in Pittsburgh on the consortium level and have found it very useful.

    When we first looked at using it, we found it frustrating that it was based by the highest ranking constituency.  We had to do a bit of finagling for the consortium wide constituency to be sure it would have the highest rank.  So far it’s worked very well, but we’ve kept it relatively simple.  Without ranking, I would think some other rule would need to be in place, but wonder if that would make it more complicated.

    _________________________________

    Rebecca Harriman

    Tessitura Operations Pittsburgh Consortium

    412.325.2230

    harriman@pgharts.org

     

    From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif
    Sent: Thursday, February 18, 2010 2:42 PM
    To: Harriman, Rebecca
    Subject: [Tessitura Next Generation Forum] Constituency Based Security

     

    When we originally designed and wrote Tessitura, there were some pieces of functionality that made their way into the system that I never really thought were fully formed or thought out.  As a result these features tend to get very little use or confuse many users.

    One such feature is constituency-based security.  This feature allows you to define rights to one or more constituent functions (i.e. editing addresses) based on the highest ranking constituency of that constituent.

    Development stories concerning constituencies are starting to come into view and we need to explore whether this security paradigm is worth continuing.

    In my opinion, the whole idea of constituency-based security loses a bit of its shine as soon as you realize that it's all based on the highest ranking constituency only.  In addition, the concept was put in place well before Control Groups was ever thought of and we might have thought twice about it if Control Groups were in the original plan.  It's not that Control Group functionality replaces constituency-based security, but rather that sometimes you have to step back and wonder whether there aren't too many layers of complexity.  Especially if one of those layers is not often used--a survey of Network implementation consultants seemed to show that very few sites ever implement this functionality, at least initially.

    Another factor prompting this thread is that several times our internal discussion on on how we might better use constituencies going forward has been hampered when someone says "yeah, but don't forget about constituencies and security".

    We've tried to model out what would happen if we changed the model so that security could be based on "any" constituency instead of "highest ranking" constituency.  But that always creates problems.  What if a constituent has both constituency 1 and constituency 2.  Constituency 1 says they're allowed to edit addresses and constituency 2 says that they are not.  What to do then?

    So some help here, please.  How many sites use this functionality now and how passionate about it are you?

    As always, thanks in advance for the feedback!




    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!

  • $organization in reply to Rebecca Harriman

    Hi Rebecca,

    Can you elaborate on how you use it, what specific business need are you satisfying by using Constituency based Security?

     

    Thanks!

    Andrew

  • $organization

    Chuck -

    We use it for a single user group that we give to admin volunteers who do data entry/updates in our system from time to time. We don't want to have access to change our board/VIP info but we do need them to be able to update Joe Schmoe's address.

    We're not terribly attached to it, and mostly used it because it was available to use. If it hadn't been available we would have figured out an alternate way of ensuring board members info wasn't changed by mistake.

    Heather
    Seattle Rep 

  • $organization
    At the Met, it is very important that a user group owns the ability to change Name/Address information.  In death and divorce, renewing subscription ownership decisions are left up to a few staff members and this prevents an inbound rep from changing such without proper channels being notified.  Also in the instance of high level donors, the address information is thoughtfully maintained using this feature.  These constituents are maintained by our major gift/patron departments.  This means though most met staff can view an address, they all cannot change them.  But I will say that it has been a bit cumbersome to maintain and get a true picture of a user's rights.  There is room for revision/improvement here as long as there is the ability for a select group of staff to control revisions on particular records.
     
  • $organization in reply to Julie Carmody (Past Member)
    At Florida Grand Opera, we have used security by constituency since we started with Tessitura. There are four constituencies that can affect who can do what to accounts: two of them refer to different major donor groups; one to members of our board; and one artists. Certain user groups have view but not edit rights to many parts of these constituent records. Here are two examples:

    Our telemarketing reps made calls from lists created for them via extraction. They kept all ticketing call notes in CSI's and telefunding notes in a special solicitation. They could also add attributes (so that they could, for instance, mark a patron as Spanish-speaking--important in Miami). They could see the General tab, Names tab, Addresses tab, ticket and subscription history, and contribution history for anyone who would be pulled on a list for them. A particular rep sold a particular patron a good subscription order that came in with a contribution that, when the membership was applied, gave this patron a constituency that automatically (in a scheduled procedure) set the "No Telemarketing" phone restriction. This phone setting in turn generated a constituency of "No Telemarketing" (another scheduled procedure), which meant that the rep could no longer see any screens in the record except the CSI screen (allowing him to see his own notes, if there was something he needed to follow up on).

    Certain high-ranking managers, over time, have not had the computer skills to be trusted with a keyboard, much less the ability to edit anything in Tessitura. For them, we have a user group that allows full access to the screens they need for information, but they can't hurt anything. They can build new accounts and add research notes, but once constituencies are applied, addresses are uneditable.

    Lucie
    ================================
    Lucie Spieler
    IT Development and Training Manager
    Editor, Season Program
    Florida Grand Opera
    ---------------------------
    8390 NW 25th Street
    Miami, FL 33122-1504

    305-854-1643 x.1521 phone
    305-856-1042 fax
    800-741-1010 ticket office
    lspieler@fgo.org
    www.fgo.org

    P please don't print this e-mail unless you really need to.

    ________________________________

    From: Tessitura Next Generation Forum on behalf of Julie Carmody
    Sent: Thu 2/18/2010 8:42 PM
    To: Lucie Spieler
    Subject: Re: [Tessitura Next Generation Forum] Constituency Based Security


    At the Met, it is very important that a user group owns the ability to change Name/Address information. In death and divorce, renewing subscription ownership decisions are left up to a few staff members and this prevents an inbound rep from changing such without proper channels being notified. Also in the instance of high level donors, the address information is thoughtfully maintained using this feature. These constituents are maintained by our major gift/patron departments. This means though most met staff can view an address, they all cannot change them. But I will say that it has been a bit cumbersome to maintain and get a true picture of a user's rights. There is room for revision/improvement here as long as there is the ability for a select group of staff to control revisions on particular records.


    From: Chuck Reif
    Sent: 2/18/2010 1:37:18 PM


    When we originally designed and wrote Tessitura, there were some pieces of functionality that made their way into the system that I never really thought were fully formed or thought out. As a result these features tend to get very little use or confuse many users.

    One such feature is constituency-based security. This feature allows you to define rights to one or more constituent functions (i.e. editing addresses) based on the highest ranking constituency of that constituent.

    Development stories concerning constituencies are starting to come into view and we need to explore whether this security paradigm is worth continuing.

    In my opinion, the whole idea of constituency-based security loses a bit of its shine as soon as you realize that it's all based on the highest ranking constituency only. In addition, the concept was put in place well before Control Groups was ever thought of and we might have thought twice about it if Control Groups were in the original plan. It's not that Control Group functionality replaces constituency-based security, but rather that sometimes you have to step back and wonder whether there aren't too many layers of complexity. Especially if one of those layers is not often used--a survey of Network implementation consultants seemed to show that very few sites ever implement this functionality, at least initially.

    Another factor prompting this thread is that several times our internal discussion on on how we might better use constituencies going forward has been hampered when someone says "yeah, but don't forget about constituencies and security".

    We've tried to model out what would happen if we changed the model so that security could be based on "any" constituency instead of "highest ranking" constituency. But that always creates problems. What if a constituent has both constituency 1 and constituency 2. Constituency 1 says they're allowed to edit addresses and constituency 2 says that they are not. What to do then?

    So some help here, please. How many sites use this functionality now and how passionate about it are you?

    As always, thanks in advance for the feedback!




    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!
  • $organization

    Hi Chuck,

     

    We are definitely looking to use constituency based security for our youth theatre groups and ‘under age’ constituents. Whilst some areas of regular constituent records would be fine to be viewed/edited by anyone, we wouldn’t want sensitive information for these particular constituencies to be viewed by all. I suppose there are loads of ways to manage this, it seems easiest for us to do it by constituency!

     

    Cheers,

    Kathleen

     

    Kathleen Smith

    Sales Manager

    Royal and Derngate

    Guildhall Road

    Northampton

    NN1 1DP

     

    tel:  01604 655738 or 01604 655708

    e:  kathleen.smith@royalandderngate.co.uk

     

     

    From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif
    Sent: 18 February 2010 19:42
    To: Kathleen Smith
    Subject: [Tessitura Next Generation Forum] Constituency Based Security

     

    When we originally designed and wrote Tessitura, there were some pieces of functionality that made their way into the system that I never really thought were fully formed or thought out.  As a result these features tend to get very little use or confuse many users.

    One such feature is constituency-based security.  This feature allows you to define rights to one or more constituent functions (i.e. editing addresses) based on the highest ranking constituency of that constituent.

    Development stories concerning constituencies are starting to come into view and we need to explore whether this security paradigm is worth continuing.

    In my opinion, the whole idea of constituency-based security loses a bit of its shine as soon as you realize that it's all based on the highest ranking constituency only.  In addition, the concept was put in place well before Control Groups was ever thought of and we might have thought twice about it if Control Groups were in the original plan.  It's not that Control Group functionality replaces constituency-based security, but rather that sometimes you have to step back and wonder whether there aren't too many layers of complexity.  Especially if one of those layers is not often used--a survey of Network implementation consultants seemed to show that very few sites ever implement this functionality, at least initially.

    Another factor prompting this thread is that several times our internal discussion on on how we might better use constituencies going forward has been hampered when someone says "yeah, but don't forget about constituencies and security".

    We've tried to model out what would happen if we changed the model so that security could be based on "any" constituency instead of "highest ranking" constituency.  But that always creates problems.  What if a constituent has both constituency 1 and constituency 2.  Constituency 1 says they're allowed to edit addresses and constituency 2 says that they are not.  What to do then?

    So some help here, please.  How many sites use this functionality now and how passionate about it are you?

    As always, thanks in advance for the feedback!



    --
    View this message online at: http://www.tessituranetwork.com/COMMUNITY/forums/p/2002/7076.aspx#7076
    --
    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!

     

    Following the critically acclaimed hit, End of the Rainbow (ends Sat 20 Feb) comes the hotly anticipated My Zinc Bed by David Hare. Starring Robert Gwilym, Jamie Parker and Leanne Best this powerful new drama is an intimate portrait of three people addicted to alcohol, their work and each other. Part of our Addicted To You season, My Zinc Bed plays the Royal Stage from Fri 26 February – Sat 13 March.

     

    To book call the Box Office on 01604 624811 or select your seat online at www.royalandderngate.co.uk

     

    The Northampton Theatres Trust Ltd. Registered in England and Wales. Company Registration No. 3640915. Registered Office: Royal & Derngate, Guildhall Road, Northampton NN1 1DP

     

    Royal & DerngateMission

  • $organization

    At Southbank Centre we are using this to ensure that our press office attach the correct constituency to their records, that can’t issue press seats unless they do. To be honest this is something that we configured during implementation and I find it rather cumbersome to manage, I would rather just trust the users.

     

    We are currently reviewing a lot of our security and this function completely passed us by, so in short we could happily live without it.

     

    From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif
    Sent: 18 February 2010 19:42
    To: Halliday, Gary
    Subject: [Tessitura Next Generation Forum] Constituency Based Security

     

    When we originally designed and wrote Tessitura, there were some pieces of functionality that made their way into the system that I never really thought were fully formed or thought out.  As a result these features tend to get very little use or confuse many users.

    One such feature is constituency-based security.  This feature allows you to define rights to one or more constituent functions (i.e. editing addresses) based on the highest ranking constituency of that constituent.

    Development stories concerning constituencies are starting to come into view and we need to explore whether this security paradigm is worth continuing.

    In my opinion, the whole idea of constituency-based security loses a bit of its shine as soon as you realize that it's all based on the highest ranking constituency only.  In addition, the concept was put in place well before Control Groups was ever thought of and we might have thought twice about it if Control Groups were in the original plan.  It's not that Control Group functionality replaces constituency-based security, but rather that sometimes you have to step back and wonder whether there aren't too many layers of complexity.  Especially if one of those layers is not often used--a survey of Network implementation consultants seemed to show that very few sites ever implement this functionality, at least initially.

    Another factor prompting this thread is that several times our internal discussion on on how we might better use constituencies going forward has been hampered when someone says "yeah, but don't forget about constituencies and security".

    We've tried to model out what would happen if we changed the model so that security could be based on "any" constituency instead of "highest ranking" constituency.  But that always creates problems.  What if a constituent has both constituency 1 and constituency 2.  Constituency 1 says they're allowed to edit addresses and constituency 2 says that they are not.  What to do then?

    So some help here, please.  How many sites use this functionality now and how passionate about it are you?

    As always, thanks in advance for the feedback!




    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!


    www.southbankcentre.co.uk

    Ticket Office: 0844 847 9910

    Southbank Centre is a Registered Charity No. 298909

    ______________________________________________________________________

    This message (and files transmitted with it) may contain confidential or copyright information. If you receive it in error, please notify the sender and delete it from your computer.

    _______________________________________________________________________
  • $organization in reply to Gary Halliday

    We do use it as we have lots of different constituencies and only certain user groups are allowed to view/edit/delete/add certain things, but we do use control groups for things too. For us it means that different user groups can see information, if they need it, but can't amend it when they shouldn't / or accidently.

    e.g. our Call Centre can see the Attributes on our Members (Private Seat Holders) records, but they would not be able to add or delete them.

    Caryl

     

  • $organization in reply to Lucie Spieler
    Thank you for starting my Friday with a chuckle -- "certain high-ranking managers" are with us all.

    -----Original Message-----
    From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Lucie Spieler
    Sent: Friday, February 19, 2010 12:26 AM
    To: McKinley, Leslie
    Subject: RE: [Tessitura Next Generation Forum] Constituency Based Security

    At Florida Grand Opera, we have used security by constituency since we started with Tessitura. There are four constituencies that can affect who can do what to accounts: two of them refer to different major donor groups; one to members of our board; and one artists. Certain user groups have view but not edit rights to many parts of these constituent records. Here are two examples:

    Our telemarketing reps made calls from lists created for them via extraction. They kept all ticketing call notes in CSI's and telefunding notes in a special solicitation. They could also add attributes (so that they could, for instance, mark a patron as Spanish-speaking--important in Miami). They could see the General tab, Names tab, Addresses tab, ticket and subscription history, and contribution history for anyone who would be pulled on a list for them. A particular rep sold a particular patron a good subscription order that came in with a contribution that, when the membership was applied, gave this patron a constituency that automatically (in a scheduled procedure) set the "No Telemarketing" phone restriction. This phone setting in turn generated a constituency of "No Telemarketing" (another scheduled procedure), which meant that the rep could no longer see any screens in the record except the CSI screen (allowing him to see his own notes, if there was something he needed to follow up on).

    Certain high-ranking managers, over time, have not had the computer skills to be trusted with a keyboard, much less the ability to edit anything in Tessitura. For them, we have a user group that allows full access to the screens they need for information, but they can't hurt anything. They can build new accounts and add research notes, but once constituencies are applied, addresses are uneditable.

    Lucie
    ================================
    Lucie Spieler
    IT Development and Training Manager
    Editor, Season Program
    Florida Grand Opera
    ---------------------------
    8390 NW 25th Street
    Miami, FL 33122-1504

    305-854-1643 x.1521 phone
    305-856-1042 fax
    800-741-1010 ticket office
    lspieler@fgo.org
    www.fgo.org

    P please don't print this e-mail unless you really need to.

    ________________________________

    From: Tessitura Next Generation Forum on behalf of Julie Carmody
    Sent: Thu 2/18/2010 8:42 PM
    To: Lucie Spieler
    Subject: Re: [Tessitura Next Generation Forum] Constituency Based Security


    At the Met, it is very important that a user group owns the ability to change Name/Address information. In death and divorce, renewing subscription ownership decisions are left up to a few staff members and this prevents an inbound rep from changing such without proper channels being notified. Also in the instance of high level donors, the address information is thoughtfully maintained using this feature. These constituents are maintained by our major gift/patron departments. This means though most met staff can view an address, they all cannot change them. But I will say that it has been a bit cumbersome to maintain and get a true picture of a user's rights. There is room for revision/improvement here as long as there is the ability for a select group of staff to control revisions on particular records.


    From: Chuck Reif
    Sent: 2/18/2010 1:37:18 PM


    When we originally designed and wrote Tessitura, there were some pieces of functionality that made their way into the system that I never really thought were fully formed or thought out. As a result these features tend to get very little use or confuse many users.

    One such feature is constituency-based security. This feature allows you to define rights to one or more constituent functions (i.e. editing addresses) based on the highest ranking constituency of that constituent.

    Development stories concerning constituencies are starting to come into view and we need to explore whether this security paradigm is worth continuing.

    In my opinion, the whole idea of constituency-based security loses a bit of its shine as soon as you realize that it's all based on the highest ranking constituency only. In addition, the concept was put in place well before Control Groups was ever thought of and we might have thought twice about it if Control Groups were in the original plan. It's not that Control Group functionality replaces constituency-based security, but rather that sometimes you have to step back and wonder whether there aren't too many layers of complexity. Especially if one of those layers is not often used--a survey of Network implementation consultants seemed to show that very few sites ever implement this functionality, at least initially.

    Another factor prompting this thread is that several times our internal discussion on on how we might better use constituencies going forward has been hampered when someone says "yeah, but don't forget about constituencies and security".

    We've tried to model out what would happen if we changed the model so that security could be based on "any" constituency instead of "highest ranking" constituency. But that always creates problems. What if a constituent has both constituency 1 and constituency 2. Constituency 1 says they're allowed to edit addresses and constituency 2 says that they are not. What to do then?

    So some help here, please. How many sites use this functionality now and how passionate about it are you?

    As always, thanks in advance for the feedback!




    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!


    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!