We want to give access to the same application but limit the access to specific work objects based on Market. We think one way, using the out of the box security model, is using one Role per Market (then Access of Role to Object and an Access When to check for a Market match with the work object). Then setting up one Access Group per subset of Markets (Roles) that we need to grant.
So we would have a fairly large number of Access Groups, all giving rise to the same Ruleset stack, but with a different set of Roles. Maybe 60 to 80 different Access Groups in use in the system, with more added over time.
Does this pose a performance problem?
E.g. is Ruleset stack created one per unique Ruleset list, or one per Access Group even if the stacks are duplicated?
Hi. I am not ware of any performance issue related to using a large number of access groups. I assume you are going to use the same Defined on Application/version and then vary the roles as appropriate. That seems reasonable to me. If that's the case, they'll be using the same ruleset list hash, so will essentially be running the same compiled versions of the rules. This means that even things like first use assembly won't be bad for the common rules. I imagine there will be places where having 80 rulesets takes longer than having 8, but I suspect they are few and far between. I'm trying to come up with a specific scenario where you might get into trouble and I'm not thinking of any.