Define Workflow Rules for Object-Level Workflows

You can define workflow rules to control the workflow process based on user-defined conditions. Rules apply to either referenced or copied object-level workflows in CDM.

You can use workflow rules in the following instances:

• State Check condition
  You can use the workflow state variable ##WS to retrieve the current state of a specified object. The workflow rule then leverages the result of this variable to apply the condition.

  This condition prevents an object from advancing to the next state when a particular condition is set. For example, a rule states that Object 1 must be in the Approved state before Object 2 can proceed to the next state. If Object 1 is not in the Approved state, then the workflow cannot be advanced.

• Value Check condition
  You can use the workflow rule variable ##WR to identify the condition that will determine if the workflow state is allowed to be advanced. The workflow rule must enforce uniqueness within the report.

  This condition can be created to determine if a particular value in an Excel object is as expected. If the particular value is not entered, the workflow cannot be advanced to the next state.

To define workflow rules for object-level workflows:

1. Open the report that you want to work with.
2. In the report tree on the left, open and check out the Excel object that you want to apply the condition to.
3. If you want the rule to check the workflow state of the object, complete the following steps:
   1. Type ##WS in a cell outside the printable range, that is, outside of the ##RS-##RE range.
   2. After the cell where you typed ##WS, type the object name.

      For example, you create a rule that will check the workflow state of the Assets object.

      Table 1: Example of the cells for a rule that checks the workflow state

      Cell F2	Cell G2	Cell H2
      ##WS	Assets	Work in Progress

   3. Save and refresh the object.
4. If you want to define a workflow rule, complete the following steps:
   1. Type ##WR in a cell outside the printable range.
   2. After the cell where you typed ##WR, specify a name for the rule.
   3. Enter the condition to be checked. This can be any value or a Microsoft™ Excel formula.

      Table 2: Examples of conditions

      Condition	Description
      =IF((Example!E10>10000),0,1)	This formula validates cell E10 in the Example worksheet to see if the value is above 10,000. The workflow can be advanced to the next state only when the value is above 10,000.
      =IF((Example!D15-5="Test"),0,1)	This formula validates cell D15 in the Example worksheet to see if the word Test is specified. If the text is not Test, the formula returns a 1, which means that the workflow cannot be advanced to the next state.

      For example, the condition =IF(H2="Approved",0,1) prevents users from advancing objects to the next state if the Assets object is not in the Approved state.

      Table 3: Example of a workflow rule that uses the workflow state rule

      Cell F2	Cell G2	Cell H2
      ##WS	Assets	Work in Progress
      ##WR	Rule 1	=IF(H2="Approved",0,1)

5. You can enter a comment for the rule after the cell where you entered the condition.
6. To enforce this rule, complete the following steps:
   1. Select the object where you want the condition to be applied and edit the workflow.

      Note: This task can only be performed on objects that have workflow inheritance disabled. Any descendant sections or report objects that have workflow inheritance enabled will inherit the new rule.

   2. Right-click the transition to the next workflow state and select and apply the condition.
   3. Save the changes.

Note the following:

• When a formula evaluates to zero (0), it means the condition is met. When the formula evaluates to anything else, the condition has not been met. This includes an empty cell or text. If the condition is not met, the workflow cannot be advanced no matter what the assigned permissions are for the users. However, if a user enters 0.01 and changes the value to appear as 0, it is considered to pass the rule.
• After you add a workflow rule, a shadow under the transition arrow indicates that a rule exists.
• If a workflow state contains a transition that is validated by a rule that no longer exists in the report, the rule is ignored.
• The workflow state names are validated when the object is opened or saved. This is useful if an object was renamed and the variable still uses the old name. An orphan variable entry is added to the Orphan Variable window. If there are multiple objects with same name used in the workflow state, the first object name in the report object tree is used.
• Workflow rules are not evaluated if someone is editing the workflow. The changes made to the workflow are saved even if a rule associated to the current transition does not pass. Workflow rules are evaluated when the workflow is moved to the next state, or when the workflow state is set, or when the current state is changed in the report object properties form. Note that this applies when changing the workflow from the object tree as well as from the user summary screen.
• After you edit and save the workflow, you optionally see a list of workflow rules that are no longer defined in any object in the report. You can leave the workflow like this, with the orphaned rules still set on the transitions, or you can remove the orphaned rules.
• If you move multiple objects to the next state in the workflow, the rules are evaluated for each object. Objects that pass the rule move to the next state while objects that fail the rule do not move to the next state.
• If a workflow rule relies on a ##D value that is no longer linked to its source because ##S was removed, the rule uses the value specified on the object. If no value exists, the rule does not retrieve a value and the object fails the rule.