Review state transition rules

Transition rules define how items move from one review state to another in a workflow and who is allowed to make the state changes. You can add and edit transition rules on workflows at any time. To learn more, see Manage company workflows. You can track items in a review cycle on the project Kanban board. To learn more, see Kanban board.

Overview

• Review state transition rules can be added to a workflow. The rules limit what state changes can be made and who they can be made by for all projects using the workflow.

• By default, existing workflows have no transition rules, so any project member can make any review state change for the projects the workflow is used by.

• A review state transition rule can contain more than one review state change.

• A review state transition rule limits which users can make the transition changes and must have at least one allowed user. To allow all project members to make a transition, select All users from the user list.

• A workflow can have more than one rule.

• If more than one rule applies to a review state change, P4 DAM uses the most restrictive rule for the workflow. For example, see Overlapping rules block a user from making a review state change.

Best practice for workflow transition rules

Best practice for transition rules:

• Create as few rules as possible to make it simpler to see how they work together in a project.

• Check the rules work as expected before using them in a live project.

• Be careful when using Any State to Any State in a rule because this blocks users not in that rule from making any state changes. To learn more, see Any state to Any state rule blocks all users from making a review state change.

Example workflow review transition rules

The following are example workflow transition rules.

For the purposes of the examples, the possible review states in the workflow are Open, In Review, Needs Revision, Approved, and Rejected.

Allow all users to make all review transitions

This is the default state for existing workflows that have no rules.

If you don't need any limits on who can change review states and what they can change review states to, there is no need to have any rules in your workflow.

Limit which users can approve or reject reviews

The rule below only allows User A, User B, and User C to approve a review.

Rule name	From state	To State	Users who can make this transition
Rule 1	Any state	Approved or Rejected	User A, User B, and User C

Result:

• Project members can change review states between Open, In Review, and Needs Revision because there is no rule for these state changes.

• Rule 1:

  • User A, User B, and User C can change a review state from Any state to any other state including Approved and Rejected.

  • Other project members can't change the review state to Approved or Rejected because they are not in the list of allowed users in rule 1.

Limit which users can change a review from Open to Approved

The rule below only allows User A to change a review state from Open to Approved without going through the In Review state.

Rule name	From state	To State	Users who can make this transition
Rule 1	Open	Approved	User A

Result:

• All project members can change all review states except between Open to Approved because there are no rules for the other state changes.

• Rule 1:

  • User A can change a review state from Open to Approved without going through the In Review state.

  • Other project members can't change the review state from Open to Approved directly because they are not in the list of allowed users in rule 1.

Limit users who can change a review from Open to Approved and from Approved back to Open

The rules below only allow User A to change a review state from Open to Approved without going through the In Review state and to take a review out of the Approved state back to Open.

Rule name	From state	To State	Users who can make this transition
Rule 1	Open	Approved	User A
Rule 2	Approved	Open	User A

Result:

• All project members can change review states between Open, In Review, Needs Revision, and Rejected because there are no rules for these state changes.

• Rule 1:

  • User A can change a review state from Open to Approved without going through the In Review state.

  • Other project members can't change the review state from Open to Approved directly because they are not in the list of allowed users.

• Rule 2:

  • User A can change a review state from Approved to Open.

  • Other project members can't change the review state from Approved to Open because they are not in the list of allowed users.

Example rules with unintended consequences

The following are example workflow transition rules that could cause an issue.

Overlapping rules block a user from making a review state change

The rules below overlap when changing a review state from In Review to Rejected.

Rule name	From state	To State	Users who can make this transition
Rule 1	In Review	Approved and Rejected	User A, User B, User C
Rule 2	Approved and Rejected	Open	User A
Rule 3	In Review	Rejected	User A, User B

Result:

• All project members can change review states between Open, In Review, and Needs Revision because there are no rules for these state changes.

• Rule 1:

  • User A, User B, and User C can change a review state from In Review to Approved or Rejected.

  • Other project members can't change the review state from In Review to Approved or Rejected because they are not in the list of allowed users.

• Rule 2:

  • User A can change a review state from Approved or Rejected to Open.

  • Other project members can't change the review state from Approved or Rejected to Open because they are not in the list of allowed users.

• Rule 3:

  • User A and User B can change a review state from In Review to Rejected.

  • Other project members can't change the review state from In Review to Rejected because they are not in the list of allowed users.

When User C tries to change a review from the In Review state to the Rejected state, they are allowed to by rule 1. However, rule 3 only allows User A and User B to make the state change. Because P4 DAM enforces the strictest rule for the state change, rule 3 is used and User C is blocked from making the change.

If the company administrator needs User A, User B, and User C to be able to make this transition, the easiest fix is to delete rule 3 from the workflow.

Any state to Any state rule blocks all users from making a review state change

It is tempting to allow a use such as the Project administrator to change Any State to Any State. Setting this rule for one or more users blocks all the other project members from changing the state of a review because this rule is always the most restrictive. For example:

Rule name	From state	To State	Users who can make this transition
Rule 1	Any state	Any state	User A

Result:

• Rule 1:

  • User A can make any review state change.

  • Other project members can't make any review state changes because they are not allowed to by rule 1.