One common administration task is specifying policy rules for controlling access to objects governed by a domain. When you create these rules, you customize the domain's access control policy. Subsequently, access control lists (ACLs) are derived from the policy for a domain and the policies of all its ancestor domains and used along with ad hoc ACLs to enforce your access decisions. For more information on ad hoc ACLs, see Rules Governing Domain-based ACLs and Ad Hoc ACLs.

An access control rule for a domain is a mapping between an object type, life cycle state, a participant, and their associated permissions. For an object type and a specific state, an access control rule specifies rights of a participant concerning access to objects of that type, in that state. For example, an access control rule might state that everyone in the Publications group has permission to read all objects of type WTDocument in the Engineering domain when they are in the Under Review state. An access control rule can also be applied to all participants except for the specified participant. For example, an access control rule might state that everyone except those in the Publications group has permission to delete all objects of type WTDocument in the Engineering domain when they are in the In Work state.

An object type specifies a category of objects that share the same attributes and functions. For example, WTDocument is an object type, and instances of that type may be found in some of the domains you have created. Since Windchill domains are hierarchical, access control rules defined for a domain are inherited by descendent domains. For example, access control rules defined for the WTDocument object type in all states within the Design domain apply to instances of the type within that domain or any descendent domains. Because Windchill types are also hierarchical, an object inherits rules defined from its ancestor types. Therefore, more than one rule may apply to a given object. For example, a rule that applies to the type AnnotationSet also applies to the type StructuredAnnotationSet. Additionally, there can be access control rules specific to StructuredAnnotationSet.

The object types displayed in the Policy Administration utility are WTObject and its descendent object types that implement the wt.access.PolicyAccessControlled interface. Additionally, either of the following statements must be true:

A participant is a principal and can be one of the following:

For details about users, group, organization, and dynamic roles, see About Participant Administration.

Most often, you define access control rules for groups, roles, or organizations. Both system groups and user-defined groups appear together on the Groups tab. Both dynamic roles and pseudo roles appear together on the Roles tab. Dealing with groups, roles, or organizations helps reduce administrative overhead by enabling you to apply rules to more than one user at a time. Sometimes, however, you need to create rules for a specific user. For example, an access control rule can explicitly deny one group member a permission that is granted to the entire group by another rule. You may also need to define rules for everyone except a certain participant. For example, an access control rule can deny the Administrative permission to all participants except the Administrators group.

Permissions represent operations that apply to an object. Permissions are described in more detail in the following sections.