About Policies

A policy defines the general behavior of the governed objects and the various states through which the object will pass during its lifecycle, the people who have access at each state, and the conditions required for changing from one state to another.

Within the policy, various types of access are defined for the roles people have in an organization. People can have different roles (and therefore different access privileges) depending on who they are and their assignments. A policy can govern more than one type of object, and an object could have more than one policy that governs it. However, a specific business object follow the lifecycle and access rules of only one policy at any one time.

You must be a Business Administrator to add or modify policies.

This topic describes:

This page discusses:

General Behavior

The general information about the policy includes:

  • The types of objects the policy governs.
  • The types of formats allowed to be checked into the object.
  • The default format automatically assigned.
  • Where and how checked in files are managed.
  • The sequences used for major and minor revisions.

Lifecycle

A lifecycle is a series of states through which a business object passes from inception to completion. When a new business object is created, it is assigned a policy that defines a lifecycle that governs all activities during each lifecycle state. Each state represents a stage in the life of the governed objects. Depending on the type of object involved, the lifecycle might contain only one state or many states. The lifecycle defines:

  • The current state of the object.
  • Who has access to the object.
  • The type of access allowed.
  • Whether or not the object can be revised.
  • Whether or not files within the object can be revised.
  • The conditions required for changing state.
  • Whether or not the state has been published. Fore more information, see Published States.

A policy can exist without any states defined (mostly to support legacy data), with these limitations:

  • No access control can be defined without any state definition.
  • Some operations, like disabling checkout history, cannot be performed since no state exists to control this.

If you create a policy without a state, MQL shows a "Policy has no STATE defined" warning.

States and Signatures

An object moves through the lifecycle by changing state. A business object could change ownership in each state. The object’s policy defines the actions that can take place in each state.

The policy specifies the persons, roles, or groups who can perform each action:

  • Approval allows promotion of an object to the next state. Within the 3DEXPERIENCE platform, the lifecycle that has been defined by an object’s policy is displayed in the State browser.
  • Signatures provide a means to authorize the promotion of an object, and to which state (branch) it will move.
  • The 3DEXPERIENCE platform retains the history of actions that take place on the business object. You can access and review this history at any time.
  • Revisions can be associated with a change in state. A revision of a business object is a special kind of copy of an object. For example, an edition of a book is a revision. The revised object may either have all of the same attribute values and the same policy or these may vary.

When an object is revised, its type and name remain the same, however, the revision label changes to identify the new object. The policy specifies the scheme for labeling revisions with letters and/or numbers.