Dynamic roles always resolve to the specific context team that is associated with the context in which the domain resides. This domain is usually in the same context as the object whose access rights are being evaluated. For example, assume the following rule is set:

Also assume that the Part Demo product context is created that has a Default domain that is a child of the /Default/PDM domain of the Demo Organization and that the Designer role is a role used in the Part Demo team. Therefore, the rules evaluated for any WTDocument objects that reside in the Part Demo context and are associated with its Default domain will include the rule for the Designer role that was established in the Demo Organization context. The Designer role will resolve to the system group associated with the Part Demo team’s Designer role when the ACL for the Default domain is calculated.

The rules evaluated for any WTDocument objects that reside in the Demo Organization context and are associated with its Default domain will not include the rule for the Designer role even if the object is associated with the Default domain. This is because organization contexts do not have associated teams to which the dynamic roles can be resolved.

If a WTDocument object is created in the Part Demo product, but is associated with a domain that is not in the domain hierarchy that includes the Default domain in the Demo Organization context, the rule for the Designer role is not evaluated. In this scenario, the context team includes the Designer role, but the policy rule is not inherited through the domain. This can happen if the user is allowed to select the domain association for the folder in which the document resides and the user does not choose the Default domain.