Good question, and interesting responses. It is obvious to me that most admins don't really understand the fundamental business rule differences between the use of Groups and the use of Roles. Roles provide much more business flexibility, not the least of which is that Role participation can be managed at the application context level, rather than at the site/org context levels. What I find, and see confirmed here, is that generally the desire of the admin to simply his/her work, the business solution is constrained and limited by a missapplied use of Groups where the core system functionality is designed to use Roles.
That said, there are a couple of features that can be leveraged to get the best of both worlds. One is the use of Shared Teams, the other, and actually more powerful mechanism is to leverage the wtRolePrincipal object (unfortunately not yet well documented).
The gist of the RolePrincipal object is that you can write ACL policy rules for this role at the org context level, and those rules will automatically be inherited by any lower level Context Team Role that has exactly the same name as the RolePrincipal. Net result: I can manage Context Team membership at the context level, but manage the ACL's for all those roles at the Org level.
Unfortunately the "right" answer generally depends on specific business requirements, so I'm not going to attempt to just post a list of recommendations. But I should caution that the use of groups rather than roles to manage all business rules has shown in many cases to be a non-scalable solution in a large complex environment. Yes, it might allow all ACL management at the Org level, but that perceived advantage evaporates with large numbers of groups being created to handle every desired variation in the specific set of permissions that need to be applied.
One specific note as you begin to investigate Roles: ROLES ARE GENERALLY NOT JOB TITLES - Roles reflect responsibilties, not titles, don't confuse the two.
Russ
