Constituency Based Security

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?

We do not use constituency security at McCarter, and while we have considered using it, we don't have a pressing need for it as far as restricting editing or viewing rights goes. We can manage this quite effectively using user groups and/or control groups.

There is one possible application of constituency based security/ranking that I always thought would be cool to implement - build a web application that would allow patrons with specific ranked constituencies access to online ticket inventory allocations available only in certain modes of sale. The idea would be to enable online vip ticketing services.  

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.

We do use Constituencies for security, but it is very limiting.   As already pointed out in many of the replies, you have the issue of only the highest ranking constituency being used to determine security, and of course, you have to make sure that the appropriate constituency is applied to the customer in the first place.  

What we would find far more useful is something more logic-based, where we could define rules that automatically apply to customers, and as customers data changes, the correct rules automatically apply.    We really need more elements exposed than just constituency for determining permissions.

For instance, the ability to create a rule such as: 

Customer is a Subscriber for more than 2 years and a Donor over Level XXX, and has a value of YYY for Attribute ZZZ,  then

User Group 1 can edit,

User Group 2 can view-only,

User Group 3 can see name in a list but no other details.

Thanks for all the feedback.

For those of you that use constituency-based security now, could the business value be achieved if you were able to put restrictions on the constituent as a whole?  So instead of saying "this user group can't edit ADDRESSES where the highest ranking constituency is x" you would say "this user group can't edit ANYTHING on a constituent if they have this restriction code"

Obviously this needs to be fleshed out a bit more but in general is something like this worth thinking about some more?

Hi Chuck

We don't use constituency-based security at all.  [In fact i still remember a long session in front of a whiteboard in our implementation project office when you talked through all of the Tess security options and convinced us that it wouldn't be useful and we could safely ignore it]

If it was made more flexible as Alan suggests, or even just specific-constituency-based (being able to put a control group on a constituency, for example, which would lock you off from editing anyone with that constituency if you didn't have that control group), I could see it enabling various stories about how we don't want specific constituents being edited at random.

On the other hand, I could also see it enabling turf wars between departments and organisations about "owning" particular constituents, which we're just getting away from, and severely disabling our progress towards the nirvana of one individual-one constituent - If Gina the  ticket seller has to sell a ticket to Julie Hotshot-Lawyer and she can't access her constituent record, what's she going to do? Well, obviously, she'll create a new record so she can complete the sale - Hullo... duplicate problem even worse.

And on the third hand, it might be useful to enable locking of specific bits of a constituent record - we have a long-standing enhancement request in to be able to lock off the gen sal for specific constituents - ones with strong preferences for very non-standard salutations, basically, who require eternal vigilance to stop people taking the liberty of switching them back to the standard version.

But that's a much more fine-grained version of constituent security, and going very far down that track probably leads to getting lost forever in the Forest Of Administrative Complexity? Si?

Chuck  - I think we could live with your option, we lock down board addresses with constituency security.  As long as a others could transact on the account, perhaps add a shipping address, CSI or whatever that would probably work well enough.  If these addresses can't be locked down then the various boards start their own official lists they can monitor and control and ignore tess, we don't want to go back to that.   We would also want to allocate seats to a group, I'm not sure if we really care if it done by constituency.

The constituency issue gets more interesting when the group account structure comes into play.  If my spouse is a board member is my address changeable but not hers?  What about the address on the joint account?  If only she gets access to the prime seats I might be offended since I buy our seats on my account.  How would this work?