Governance principles

The governance aspects of Decision Center are based on the states of releases and activities, and on the governance roles of participants who work on these releases and activities.

State: The state of a release or activity can be one of In Progress, Ready for Approval, Complete, or Canceled. The state of a release can also be Rejected. The state of a release or activity dictates what work can be done and by whom.
Governance Role: All releases and activities have an owner and an approver role. Change activities also have an author role, and validation activities have a tester role. Users with administrator privileges can carry out the governance operations of all roles, and the owner of a release or activity can carry out some of the operations on behalf of participants with other roles.

When you create a release or a change activity, Decision Center takes a snapshot to record the starting state of the release or activity. A transition from one state to another can generate automatic snapshots or merges. Most notably, when all the approvers approve a change activity, Decision Center takes a snapshot to record the state of the rules, and then merges the changes back into the release.

Release governance

The user who creates a release:

Sets the owner of the release.
Sets the goals of the release.
Sets the date when the release must be completed.
Assigns one or more participants as approver of the release.
If security is implemented, sets which groups of users can access the release.

As long as the release is in the In Progress state, the owner can perform the following actions:

Change the owner of the release.
Change the goals of the release.
Change the due date of the release.
Create change and validation activities.
Modify which groups can access the release.

When all the activities of the release are complete, the release owner changes the state of the release to Ready for Approval. The approvers can then approve or reject the changes to the release.

The following diagram shows the lifecycle of a release, with manual transitions being done by the owner of the release:

The following table shows the most frequent user operations on a release, the role that is required to do the operation, and the state of the release afterward:

User operation	Role	Release state after operation
Create release	-	In Progress
Cancel release	Owner	Canceled
Reopen release	Owner	In Progress
Proceed to approval	Owner	Ready for Approval
Reject changes	Approver (or owner on behalf of approver)	Rejected
Approve changes	Approver (or owner on behalf of approver)	Complete
Delete a release	Owner Note: Can be done only in the Enterprise Console, on releases that are not Complete (see the section on Managing subranches in the Enterprise Console documentation).	-

Change activity governance

When the release is In Progress, any user can create change activities and assign the initial owner.

Then, as long as the change activity is not Complete, the owner of the activity can do the following actions:

Change the owner of the activity.
Change the due date of the activity.
Change the goals of the activity.
Assign approvers and authors to the activity.
If security is implemented, set which groups of users can access the activity.

Authors edit rules in a change activity. When they finish their work, authors change their status to Finished. When all the authors finish their work, the owner of the change activity acknowledges that the work is done by setting the state of the change activity to Ready for Approval. Then, the approvers approve or reject the changes. If there are no approvers, the change activity is automatically approved.

When all the approvers approve the change activity, Decision Center merges the changes back into the release. The change activity is then Complete. When a change activity is rejected, it returns to its state of In Progress.

The following diagram shows the lifecycle of a change activity, with manual transitions being done by the owner of the activity:

The following table shows the most frequent user operations on a change activity. It shows the role that is required to do each operation, the precondition to this operation, and the state of the change activity afterward:

User operation	Role	Precondition to the operation	State of activity after operation
Create activity	-	-	In Progress
Cancel activity	Owner	-	Canceled
Reopen activity	Owner	Activity is in Canceled state	In Progress
Proceed to approval	Owner	Authors finish work	Ready for Approval
Finish working	Author (or owner on behalf of author)	Author working	In Progress
Resume working	Author (or owner on behalf of author)	Author finishes work	In Progress
Approve changes	Approver (or owner on behalf of approver)	Activity is in Ready for Approval state	Complete
Reject changes	Approver (or owner on behalf of approver)	Activity is in Ready for Approval state	In Progress
Delete activity	Owner of the activity or the release.	Can be done only on activities that are not Complete or Canceled	-

Validation activity governance

When the release is In Progress, any user can create a validation activity for the release and assign an owner to the activity.

Then, as long as the validation activity is not Complete, the owner of the activity can do the following actions:

Change the owner of the activity.
Change the due date of the activity.
Change the goals of the activity.
Assign approvers and testers to the activity.
If security is implemented, set which groups of users can access the activity.

Testers run different tests that are aimed at validating a release, and note the results in the test plan. When they finish their work, and all the change activities of the release are Complete, testers change their status to Finished. When all the testers finish their work, the owner of the validation activity sets its state to Ready for Approval, at which point the approvers approve or reject the activity.

When all the approvers approve the validation activity, Decision Center sets the state of the validation activity to Complete.

Note: If a user creates a change activity in a release that contains a Complete validation activity, this validation activity is reopened.

The following diagram shows the lifecycle of a validation activity, with manual transitions being done by the owner of the activity:

The following table shows the most frequent user operations on a validation activity. It shows the role that is required to do each operation, the precondition to this operation, and the state of the validation activity afterward:

User operation	Role	Precondition to the operation	State of activity after operation
Create activity	-	-	In Progress
Cancel activity	Owner	-	Canceled
Reopen activity	Owner	Activity is in Canceled state	In Progress
Proceed to approval	Owner	Testers finishes work	Ready for Approval
Finish working	Tester (or owner on behalf of tester)	Tester working	In Progress
Resume working	Tester (or owner on behalf of tester)	Tester finishes work	In Progress
Approve changes	Approver (or owner on behalf of approver)	Activity is in Ready for Approval state	Complete
Reject changes	Approver (or owner on behalf of approver)	Activity is in Ready for Approval state	In Progress
Delete activity	Owner of the activity or the release.	Can be done only on activities that are not Complete or Canceled	-