Use rules to customize how you work

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.

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



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 conditions.


Save the changes.

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

Back to top


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 Enabling and handling 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: