You can set up rules that trigger actions in ALM Octane when certain conditions are met.
Rules contain an action and usually a condition.
You set the action that should occur when the condition is true.
Examples of actions include making fields required, making fields read-only, setting a default value for a field, and so on.
When conditions are met, the rule's action is performed. For example, a rule can make the Fixed in Release field required if the Status field is changed to Fixed. Status=Fixed is the condition.
If you don't specify a condition, the rule's action is always performed. For example, you may want a field to always be required.
Space admins and workspace admins can modify values for rules.
Admins without Administration > Rule > Manage permissions can view the Rules area in Settings, but cannot make any updates.
Rules can be defined for shared spaces and workspaces.
Rules cannot be defined at the space level when the space is isolated.
Instead, workspace admins define rules in individual workspaces.
The rules are applied in that individual workspace only.
Shared spaces (Enterprise Edition)
This table summarizes the actions admins can perform when defining rules in shared spaces and associated workspaces.
|Shared space||Associated workspaces|
The space admin can add and modify rules defined in the shared space.
The rules run in all associated workspaces.
Which rules run first?
Individual workspace rules run first, and then shared space rules. For details, see Do shared space rules or workspace rules take precedence?.
Rules can be defined for shared spaces and workspaces.
See how to define rules
Watch a slideshow that shows you how to work with rules:
Create a rule
Depending on the rule you are defining, there may be some preliminary steps to take before starting.
For example, if you are creating a rule with the Trigger Webhook action, you may want to define credentials before creating the rule.
In Settings , click Spaces and select a space or a workspace.
Click Entities and select the item for which you want to create a rule.
You can create a new rule or use an existing one as a basis:
Click + to create a new rule.
Select a rule and click Duplicate Rule.
Define an action
Click Action and choose the action for the rule to perform.
Enter the relevant values for that action.
Make fields mandatory.
Make fields read-only.
|Modify Lookup List||
Change the values for lists to a subset of the list.
Enter the name of the list you want to use. For details on creating lists, see Set up lists.
Enable users to select different form layouts for adding and editing entities.
The form layout must be pre-defined in Customization > Forms.
|Set Field Value||
You can either:
Timing is the trigger that causes a value to be set. The timing can be:
The value can be a new value, empty, or a copy of another field's value.
ALM Octane supports webhooks for integrating with other applications. Configure the webhooks by creating a rule with the Trigger Webhook action.
Configure the following:
For end-to-end instructions on working with Trigger Webhook rules, review Trigger webhooks for other applications.
Send an email if an entity is created, changed, or deleted.
Submission mode is the trigger that causes the email to be sent.
Email recipients can be users defined in the project or users whose names appear in fields' lookup lists.
The body of the email is generated automatically by ALM Octane.
If an entity matches the rule condition, an error dialog is opened with a message you define. The entity cannot be saved until the user modifies the entity and the entity no longer matches the rule condition.
Note: The condition should contain criteria that are not desirable. We want the rule to alert users with an error dialog box only if there is a problem. The condition specifies a problematic scenario, not a legitimate one.
You can have the rule alert users when an entity is created, changed, or deleted. Submission mode is the trigger that causes the rule to run.
Tip: You can use this rule action to prevent a user with a certain role from performing an action under certain circumstances. For example, if a rule action for creating a user story is Alert User, and the rule condition indicates the release that the user is not allowed to work in, if the condition is true, the user cannot work in that specific release—even if generally, the user has permissions to do so for other releases.
Add a comment to the entity when an entity is created or updated.
Submission mode is the trigger that causes the comment to be added.
|Assign to Users||Adds an item in the My Work module for the user assigned to the selected type (author, detected by, owner, QA owner).|
Prevent users from transitioning from one phase to a specific phase, even though the transition is generally permitted in the workflow for the entity.
Tip: 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 tab.
A condition is made up of a field, an operator and a value.
Click Condition to start creating the condition.
Only one condition can be defined for each rule. But the condition can be a complex condition: This means that you can have one condition with several parts, separated by And and Or operators.Select a field
Select a field on which to base the condition, or a special circumstance.
Special circumstances include:
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)
Current User role The condition is based on whether a user is assigned a specific role. <entity> count
The condition is based on how many related items of a certain type exist.Examples
Find features not associated with any application modules:
Select the feature entity.
Select Application module count for the Field value.
Select the = operator.
Enter the value 0.
Select an operator
Find features with tags that I created:
Select the feature entity.
Select Tags count for the Field value.
Click and then Add FIlter.
Tip: If no exists, another way to get a relative count is to select the Filter operator. For details, see Filter operators.
Select Author > Equal to > Me.
Select the > operator.
Enter the value 0.
Click OK twice.
Depending on the selected field or special circumstance, different operators are available. For example, date fields display different operators than text fields.
In addition to typical operators (=, <, >, and so on), some fields support special operators, such as:
Checks if the field contains the values you select from a list.
Checks if the current user role includes the roles you select from a list.
Available only for the circumstance Current User Role.
Checks if the field is empty.
Checks if the field is modified from its original value. This operator is not available for new entities.
Current and Original operators
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.
Available for count fields:
You can set conditions that count items related to the current item. For example, you can count all features that have tests that I own.
Select the feature entity.
- In the list of operators, scroll down and select an operator under Filter.
Select an operator, such as =.
Define a filter. For example, you can define a filter for Owner > Equal to > Me.
Tip: If no Filter operators exist, you can filter the count by selecting the icon. For details, see Counts of items related to other entities.Set a value
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.
For user fields, you can enter [Current User] as a value. If necessary, add AND/OR expressions to the condition.
If necessary, add AND/OR expressions to the condition.
As you build the condition, a textual representation of the condition is displayed in the Description box.
Note: 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. There are situations where this is not an error, but part of the logic necessary to implement your organization's policy.
By default, rules are activated. For details, see Understand rule activation and performance.
After you save the rules, ALM Octane automatically runs them.
Examples of creating rules are listed below.
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.
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.
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.
For webhook integration with another application when an entity is created, deleted or updated, you can use a Trigger Webhook rule to POST a request to an endpoint URL. The service at the URL receives the call and processes the request.
Actionable upon: New, Update, Delete
Action: POST ALM Octane entity information to the endpoint URL: http://myServer:8081/myAPI.
For details on setting up Trigger Webhook rules to POST information to endpoint URLs as a result of an event, see Trigger webhooks for other applications.
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.
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.
Developers should not be able to close defects, so we can create a workflow rule that blocks this transition.
We recommend you create the rule from the Workflow tab for the entity. This way, the From and To phases for the transition are already entered for you. Select the transition between Proposed Closed and Closed, and add a rule using the Rules panel.
Condition: If the Current User Role includes Team Member...
Action: Block transition from Proposed Closed to Closed.
Testers work on different releases.
First, ask your space admin to make sure that the tester role has create/edit permissions for defects. For details, see Assign roles and permissions.
Then we add an Alert User rule with a condition that lists the releases for which the tester cannot update defects.
If the condition in the rule evaluates to true, the rule alerts the user that the updates violate the specified condition and prevents all updates to the defect.
Action: Alert the user when creating, modifying or deleting a defect if the condition indicates a problem (meaning, the condition evaluates to true).
Condition: If the Current User Role includes Tester, and Release equals a forbidden release, the condition evaluates to true. The user is alerted and updates are prevented.