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!
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
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!
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
We use it in our consortium to make certain records read only for specific staff members. So, for example, if a customer is on the leadership council of one of our consortium members, staff members at other organizations would not be able to update his or her address directly.
Although it is in use here, I don't think that we are particularly attached to the constituency security functionality as it exists today, especially given its limitations. More important for us is the general ability to limit which users (by user group or control group or some other mechanism) can take specific actions on a given account, based on some piece of information that is specific to the customer.
We have just started to use constituency-based security. I was recently asked by our Director of Development to restrict the viewing of staff contribution records to a few select senior Finance and Development staff members. User group security restricts the Contributions tab from a number of groups. However since the contributions tab is accessible by all development user groups that share other development control group securities and we want to restrict access to staff contributions to just a couple of the user groups I have set up restrictions such that any contributions tab in a record with the STA constituency is accessible only by the two selected user groups.
So thanks for all the great feedback. Using Duane's comment as an example, is STA your highest ranking constituency? If not how will you deal with the fact that a constituent with an STA constituency might also have a higher ranking one, say VIP?
Or do those of you that use constituency-based security just accept that as a limitation and deal with it?
Hi Chuck,
In Yale's case, I would say we just deal with the limitations. We are trying to manage too many groups and constituencies to have a setup that ensures that the most applicable constituency will always be ranked the highest.
We have communication and notification strategies in place so that if someone does make a change to an important constituent, all of the appropriate staff members are aware of it.