Share this page

# Manage the workflow

This topic provides an overview of how to manage the OpenText Dimensions CM workflow by using lifecycles, roles and privileges, object attributes, and notifications.

In this topic:

## Lifecycles

In OpenText Dimensions CM, a lifecycle defines the approval process for object types.

Items, requests, projects/streams, and other OpenText Dimensions CM objects have lifecycles associated with them to enable each object to follow a path of approved states.

For details about OpenText Dimensions CM object classes, see OpenText Dimensions CM objects.

Lifecycle guidelines:

- You can define a lifecycle independently and then associate it to an object type in the Administration Console, or you can define a lifecycle from within the context of an object type.

- Each object follows the lifecycle of its associated object type. The status of an object is its current state in its lifecycle.

- The process of moving an object to a given state from another state is called actioning. Normally, an object in a specific state can be actioned only to certain other states.

- Lifecycle stages and rules define the transition of objects from one state to another. Only users with the appropriate role for a specific state can action an object to another state.

- You can define different types of objects and have them follow different lifecycles. You can set up the necessary privileges to determine which users are allowed to action (promote) an object through a given state transition.

  For example:

A lifecycle consists of:

Element | Description
--- | ---
States | Approval levels through which an object must pass. States typically reflect process states such as development, test, and release.
Transitions | The permitted movement of an object between one state and another state. Transitions determine the sequence of states for a lifecycle.
Roles | The role holders who can action an object from one specific state to another.
Normal and off-normal states | States that indicate how an object is progressing through the lifecycle. Normal states follow a progressive path through the lifecycle. Off-normal states are not located on this path and represent a failure or a need for rework.

For example:

Lifecycles ensure that an organization's processes are followed and are auditable. Lifecycles are user-defined so that they reflect the way in which the organization works.

Lifecycle example:

The following lifecycle for a source file has the Unit Tested state selected. Normally, an item reaches that state when a developer actions the item from the Under Work state. Only a Team Leader can then action the item from Unit Tested to Approved. The only other transition possible from Unit Tested is to Rejected, which only a Team Leader can make.

Example: Document lifecycle

The following diagram illustrates a simple item lifecycle for a document. Only a user with the Developer role can action the object from DRAFT to UNDER REVIEW. Only a user with the Team Leader role can action the object from UNDER REVIEW to APPROVED.

Note: You can assign more than one role to a transition.

The DRAFT, UNDER REVIEW, and APPROVED states form the normal path for the lifecycle. WITHDRAWN and REJECTED are off-normal.

Example: Single-state lifecycle

For item types, you can create lifecycles that consist of only a single state. As in the following example, a single-state lifecycle may be used for intermediate derived files such as compiled output files, which do not normally follow an approval procedure.

A single-state lifecycle has one normal transition with the same begin and end state. An item assigned to a single-state lifecycle is not displayed on any item inboxes.

Note: You cannot action an object with a single-state lifecycle.

Back to top

## Privileges, roles, and rules

The privileges and/or role assignments defined for your user in the Administration Console determine the operations you can perform and the object classes on which you can perform them.

A privilege is the ability to perform a certain operation on a specific class of object, such as creating a project or actioning a request. It can also be the ability to perform a general administrative function, such as managing lifecycles or privileges.

A role is a set of privileges that can be assigned to one or more users, enabling the users to carry out activities required for a certain position within the organization, for example Developer, or Team Leader.

Using permissions, you can:

- Assign users or groups of users and grant them privileges for certain actions, such as create or update, under a given set of conditions (rules).

- Assign the authority to action objects for different stages in the lifecycle.

For details, see Privileges and roles.

Back to top

## Attributes

an OpenText Dimensions CM object can have a number of attributes that record and track configuration information about it, such as creation date, owner, status, or description.

The following objects have a set of attributes specified in the process model: items, requests, baselines, design parts, users, and products.

You can view, filter, and report on objects using these attributes. You can enable only certain users to update attributes at specified lifecycle states.

Attributes can be system-defined or user-defined:

Type | Description
--- | ---
System-defined attributes | These are predefined by OpenText Dimensions CM for the object class. They are often used by OpenText Dimensions CM to maintain certain data about the object, for example Creation Date or Current Status.
User-defined attributes | These are defined in your process model for a specific object type. For example, an item of type Source may have an attribute called Lines of Code, whereas an item of type Object may have an attribute called Platform.

Attributes can have different formats, such as Text or Date. They can be multivalue, when a field has more than one value, or multifield and multivalue, when an attribute consists of several fields with more than one value.

For details about working with attributes in the Administration Console, see Use attributes.

Attribute rules

You can set attribute rules that define the following conditions for a specific lifecycle transition:

- Whether the attribute is visible to the user.

- Whether the user can update the attribute.

- Whether the attribute is required, which means that the user must update the attribute before they can action the object.

Valid sets

You can define sets of rules that allow users to specify only certain values for an attribute. You can also define a validation that cross-checks field values and automatically fills in the dependent fields when the user enters an attribute value.

You create a valid set and then assign it to one or more user-defined attributes in the Administration Console.

Back to top

## Sensitive attributes and lifecycle states

When you define an attribute or lifecycle state, you can specify it as Sensitive for security purposes.

If an attribute is sensitive, users need to re-enter their password before they can update the attribute.

If a lifecycle state is sensitive, user need to re-enter their password before they can action the object to or from that state. This is called an authentication point.

OpenText Dimensions CM maintains an audit trail of all failed and successful authentication attempts.

Authentication points are generated only for requests and items. They are not generated for held requests.

The following actions require authentication:

- Actioning an item or request to or from a sensitive lifecycle state, unless the sensitive state is the first normal lifecycle state and you are creating the object.

- Modifying the value of a sensitive attribute, unless the modification occurs as part of creating the object.

- Deleting an item or request when it is at a sensitive lifecycle state.

Authentication points in the Administration Console:

- When changing a lifecycle state's sensitivity, unless this is done as part of creating the lifecycle state.

- When changing an attribute's sensitivity, unless this is done as part of creating the attribute definition.

- When deleting a sensitive lifecycle state, including automatic deletions that occur when you delete the last transition involving the state, or delete the entire lifecycle.

- When deleting a sensitive attribute definition.

Back to top

## Change Management rules

Change Management (CM) rules are a special category of rules for items and/or requests that enable better control over planning, implementing, and closing changes.

You set up Change Management rules in the Administration Console.

A set of rules defined for a request type organizes a request's lifecycle states into phases. You can configure phases that determine what request operations can be performed, for example:

Then you can assign the lifecycle states for a request type to those phases, for example:

The phases define the operations that can be performed when the request is at a specific state.

You can also configure certain rules for item types. For example, the rules can require item revisions to be related to requests at various states in its lifecycle. This way, CM rules bring version management and change management closer together, ensuring that related items and requests progress through their lifecycles in tandem. For details, see Link version and change management.

For details about Change Management rules and how to enable them in the Administration Console, see Use Change Management rules.

Back to top

## Upload rules

Use upload rules to map file name patterns to OpenText Dimensions CM file formats and item types.

Upload rules determine whether files that match a certain name pattern can be added to the database using an OpenText Dimensions CM client or an IDE, and if so, what item types the files are created as.

Upload rules must exist in the base database before you can start adding files.

Back to top

## Inboxes and notifications

You inbox contains objects awaiting your action.

You can view your inboxes for each object class. You may be able to perform only certain actions on an object in your inbox.

OpenText Dimensions CM has a sophisticated facility for configuring email notifications that can be sent to specified users when certain events occur. You can define the conditions for triggering emails, and the users to receive those messages. OpenText Dimensions CM can “digest” multiple messages to reduce the number of emails.

For details about email notifications, see Manage notification emails.

Back to top

## Electronic signatures

In your environment, you may need to have an electronic signature applied, either when a specific object type is actioned to a certain state in its lifecycle, or a specific object attribute is updated.

OpenText Dimensions CM has the ability to define authentication points, which prompt you to re-enter your user credentials when you perform specific actions. OpenText Dimensions CM keeps an audit trail of all such authentication attempts.

Back to top

See also:

- Control assets
- Version management

https://admhelp.microfocus.com Dimensions CM 8942
Tips to improve your search results... OpenText™ Dimensions CM Help Center OpenText™ Dimensions CM Help 25.2 All View Local Help Center View Online Help Center Version: