Set up rules for workflow

Rules customize the ALM Octane user interface and control actions users can perform. The rules enable administrators to implement and enforce organizational, departmental, and group policies for the workspace. Rules perform these activities without explicit user intervention.

Workspace admin permissions are required.

The parts of a rule

Rules contain an action and usually a condition. You set the action that should occur when the defined condition is true.

Actions Conditions

Most actions affect fields. These actions generally affect organizational policy. You can: 

  • Make certain fields required.

  • Make certain fields read-only.

  • Change the values for field lookup lists to a subset of a lookup list.

  • Set a default value for a field when creating or changing an entity.

  • Set a value for a field if the value of another field changes.

  • Use other forms.

  • Add comments.

  • Send an email if an entity is created, changed, or deleted.

  • Validate an entity when it is created, changed, or deleted.

  • Call a URL when an entity is created, changed, or deleted.

Some actions affect forms, such as enabling users to select different form layouts for adding and editing entities. These actions affect usability.

Conditions, when met, cause the rule's action to be performed. Conditions can be based on a value of a field or on the group associated with a user.

You don't have to specify a condition, but you can. If you don't specify a condition, the rule's action is always performed.

ALM Octane evaluates complex conditions only until the condition evaluates to either true or false, and then does not continue evaluating the rest of the complex condition.

  • If ALM Octane evaluates an OR condition, and the first part of the condition evaluates to true, there is no need to continue evaluating the second part of the condition. The complex condition is met.

  • If ALM Octane evaluates an AND condition, and the first part of the condition evaluates to false, there is no need to continue evaluating the second part of the condition. The complex condition is not met.

Tip: Conditions can evaluate to false if ALM Octane encounters a field in a rule definition that it cannot process because the field does not exist. Sometimes this is because a field was removed from the project.

However, there are situations where this is not an error, but part of the logic necessary to implement your organization's policy.

Back to top

Work with rules

Plan

 

Think about the rules you need. What use case should your rules handle? What should the rules achieve?


  • There may be a use case for which several rules are needed. For example, to set different lookup lists based on a field value, you need a rule for each lookup list.


  • The order in which the rules appear in the rule list is also important. Later rules override the actions of earlier rules.

For details, see Define and run rules.

Define actions

Define what actions to perform in the Action tab.


In this tab, you can also:


  • Add remarks that explain the purpose and logic behind the rule.

  • You can also describe the use case, as determined during the Plan phase.


  • Deactivate the rule. (Rules, by default, are activated.)

For details, see Define rule actions.

Define conditions

Define when actions are performed using conditions in the Condition tab. 



  • The condition can be based on a value of a field.

  • Don’t define a condition if you want the action to be performed under all circumstances, meaning, unconditionally.

For details, see Define rule actions.

Save

Save the changes.

Once saved, expect the rules to run in real-time.

Watch a slideshow that shows you how to work with rules!

Back to top

Define and run rules

Rules are defined on a workspace-by-workspace basis.

  1. In Settings , click Workspaces and select a workspace.

  2. In that workspace, click Entities.

  3. Select the item (such as user story, manual test, epic, and so on) for which you want to create a rule.

  4. Click the Rules tab.

    Tip:  

    • Rules that are not defined correctly display with a and individual fields display with a red border.

    • You can filter the rules you see in the grid. Using the text box at the top of the grid, enter text. Only rules whose Action, Condition, or Remark contain this text are listed in the grid. To clear the filter, erase the text in the text box.

    • To define phase-dependent rules, click the Workflow tab, select a phase or transition for which you want to create a rule, and click the Rules sub-tab.
  5. Click +, or select a rule and click Duplicate Rule.

  6. Set the rule's action and condition. See Define rule actions and Define rule conditions.

    Rules are added to the Rule list. Added rules are appended to the end of the rule list. Duplicated rules are added after the selected rule.

    By default, rules are activated. For details, see Understand rule activation and performance.

  7. Click Save.

After you save the rules, ALM Octane automatically runs them.

Back to top

Define rule actions

  1. When creating or editing a rule, click Action.

  2. Define the action you want the rule to perform.

    For this action... Enter the following...
    Make
    required
    • The field you want to make required.

    Make read-only
    • The field you want to make read-only.

    Modify lookup list
    • The field whose list you want to change.

    • You can limit the options in the lookup list by selecting specific values from the lookup list.

    Use form
    • A pre-defined form layout, created in Customization > Forms.

    Set field value
    • The trigger that causes a value to be set, which can be when an entity is created, or an entity field is changed. This is called Timing.

    • The field whose value you want to set.

    • The new value, empty, or a copy of another field's value

      When setting a date value, the [Date of change] option sets the date to the date the change was made.

    Call URL
    • The trigger that causes the script at the URL you specify to be called. This is called Submission mode. The rule can be triggered when an entity is created, updated, or deleted.

    • The URL you want to call.

    • Advanced Settings (depending on environment): 

      On-premises:
      • If the URL can be accessed from your network, no bridge is needed.

      • If the URL cannot be accessed from your network, install an Integration Bridge on a server that can open a connection to the target server of the Call URL action. See Set up the Integration Bridge

      SaaS:
      • If the URL is publicly visible, contact your SaaS administrator and request that SaaS enable a call to the URL.

      • If the URL is inside your private network and it is not publicly visible, you need to install an Integration Bridge inside your network. See Set up the Integration Bridge

    Note: Before activating rules that call URLs, follow the instructions under Enable and handle rules that call URL scripts.

    Send email
    • The trigger that causes an email to be sent, which can be when an entity is created, deleted, or changed. This is called Submission mode.

    • The recipient, which can be users defined in the project or users whose names appear in fields' lookup lists.

    • The subject of the email.

      (The body of the email is generated automatically by ALM Octane.)

    Validate
    • The trigger that causes a validation to be performed, which can be when an entity is created, deleted, or changed. This is called Submission mode.

    • The validation type, either error, warning, or information.
    • The text of the validation message.

    Add comment Adds the entered comment to the entity when an entity is created or updated.
    Assign to users Adds an item in the My Work module for the selected users. Use this rule to define when a user sees an item (depending on phase) in their MyWork module.
  3. Add remarks to explain the purpose and logic behind the rule.

Back to top

Define rule conditions

  1. When creating or editing a rule, click the Condition tab.

  2. Create the condition.

    Note: Only one condition can be defined. The condition can be a complex condition.

    1. In the Field box, select a field on which to base the condition, or a special circumstance.

      Tip: Start typing a field name in the corresponding box to search and select from a list.

      Special circumstances include: 

      • Edit Mode. The condition is based on whether the current entity existed already and is now being edited, or if the current entity is new.

        To check if new: Edit mode = New

        To check if existing: Not(Edit mode = New) 

      • User roles: The condition is based on whether a user has a specific role.
    2. In the Operator box, select an operator.

      Depending on the field, different operators are available. For example, date fields display different operators from text fields.

      You can set conditions that assess the original value of a field (when the entity was first accessed) or the current value of a field (because you may have changed the field value since the entity was initially accessed).

      • To base the condition on the original value, select an operator under the heading Original in the operator drop-down list.

      • To base the condition on the current value, select an operator under the heading Current in the operator drop-down list.

      In addition to typical operators (=, <, >, and so on), some fields support special operators, such as:

      contains

      Checks if the field contains the values you select from a list.

      include

      Checks if the User's Group contains the user groups you select from a list.

      is empty

      Checks if the field is empty.

      is modified

      Checks if the field is modified from its original value. This operator is not available for new entities.

    3. In the next box, enter a value. You can enter a value or select one or more values from a list. If you select multiple values, they are connected with an Or statement.

      Tip: Start typing a value in the corresponding box to search and select from a list.

  3. If necessary, add additional expressions to the condition by choosing AND or OR in the Gate box and clicking .

    As you build the condition, a textual representation of the condition is displayed in the Description box.

    You cannot save the rule if there are errors. Errors include syntax errors, such as an unclosed set of parentheses, or context errors, such as a referenced user-defined field or form being deleted.

  4. Click OK.

Examples

Switching Lookup lists

You can create a rule that assigns different lookup lists for defects' severity based on the release. For example, the available severity values for release 1.16 might be 1-Low, 2-Medium, and 3-High, while for release 2.00, the available severity values might be 1-Low, 2-Medium, 3-High, 4-Very High, and 5-Urgent.

Condition: If a defect's Release field is 2.00...

Action: Use a different lookup list for the defect's possible severity values (such as Old_Severity_Values, New_Severity_Values).

Setting a subset of a Lookup list

Depending on the current team, certain item origins for defects are not available. For example, if a certain team only works with ALM and ALM Octane, the item origins for that team's defects cannot be Service Anywhere or JIRA. You can create a rule that makes only a sub-list of the current lookup list available, based on the team.

Condition: If the Team field is a specific value...

Action: Select the Item Origin values that are relevant to that team.

Making fields required

Make the testing tool type required to prevent empty values for automated tests.

Condition: If the Testing tool type field Is Empty...

Action: The Testing tool type field is required.

Setting default field values

To make sure each manual test is assigned to an application module, set the Application modules field value to a default application module for all empty statuses.

Condition: If the Edit mode for the test is New, it means the test was just created and...

Action: Set the Application modules field to General.

Calling a URL

To support advanced workflow use case scenarios and integrate with external applications, you can use Call URL to trigger a third party script embodied in an endpoint URL.

Condition: <None>

Actionable upon: New, Update, Delete

Action: Call a script at the http://myServer:8081/myAPI URL.

For details on setting up rules that call URLS, see Enable and handle rules that call URL scripts.

Switching forms

When a tester creates a defect to report a bug, organizational policy dictates that the tester be able to view and edit the following fields: Description, and Severity.

Similarly, when a developer starts fixing a defect, the developer must be able to view and edit the following fields:  Fixed on, Fixed in Build, and Owner.

Define two rules:

  • Rule 1: Sets a form for developers.

    Condition: If the team is the Developer team...

    Action: The form for developers is used.

  • Rule 2: Sets a form for testers.

    Condition: If the team is the Tester team...

    Action: The form for testers is used.

Send an email when a item's attribute's are updated

When a user story, defect, or other item changes its status, you may want to be notified that such an item has been updated.

To do this, you define it in one the following ways:

  • If you want to be notified of any change in a specific field - such as the phase of an item - select Is Modified as the operator for the field
  • If you want to be notified of a change in specified field to specific value - such as a defect moving from Opened to Fixed - set the Original = field to the previous value and the regular operator to = for a new value

Back to top

Next steps: