|Posted: 2014-09-17 09:49|
I've read a number of the permissions articles / discussions about controlling what users can do through user groups. They seem to concentrate on what user can do with each 'object type' - so teleales people can deal with leads but not invoices and cases etc - which is useful.
I think I've got a slightly differnet problem through, so I'm wondering about any approaches to it. To impliment a bit of regional control we'd like to split access to leads, people, organisations (and possibly many other things) on a regional basis - so I could have a "UK" user group and an "Australia" user group, and they could only see leads somehow assigned to their own country.
If I put permissions on a 'Australia' lead queue (or other object queue) to make it only visible to Australian user group (and global managers group etc that we can ignore for now), and then put leads into and out of that queue, does that control who can see / not see those leads, or is it based on the permssions of the lead itself? (If so, can automation be devised to spot the queue of the lead, or some other attribute, and set permissions based on that?)
Or are there any other suggestions on how to manage that?
Thanks in advance,
|Posted: Thu, 18.09.2014 - 12:06|
Your first point addresses Capabilities, which you're right, grant users the ability to access certain parts of the system. However they do not give varying levels of access to the same object types - this is where permissions come in.
Permissions are typically based upon the ownership of a record. So you can configure rulesets - i.e., the rules which define the level of access - to apply when a record is owned by a user found in a user group. It is then possible to set up a permissions structure so that regional areas only have access to records owned by users in their regional user group. This is not an unusual configuration and many of our customers employ this type of setup. You'll find an example as to how this can be achieved on our Knowledge Base.
You mention enforcing a level of access depending on who the record is assigned to, in particular if a record is assigned to a queue, it's worth noting that there is a subtle caveat surrounding this.
In this situation, as permissions are determined by the ownership of a record, you'll need to be aware that assigning a record to a queue does not change the ownership of a record. Therefore if you were in the UK group and created a record but assigned it to the Australian queue, as the record was created by a UK user, the ownership would be from a UK user and thus the permissions applied would be that of a UK user, even though the record is assigned to the Australian queue. To get around this you would either need to assign the lead to an Australian user first to force the change of ownership, or get an Australian user to create the record in the first place.
It would be possible to create automation surrounding this to force the change of ownership when a record is assigned to a queue, however it would require engineering resource and would therefore be chargeable, if you'd like to find out more, please contact firstname.lastname@example.org and we can discuss it further.
Hope this helps.