This section describes how ALM Octane decides which rule actions to perform and when to perform them. It also discusses the significance of the order of the rules in the grid.
Most rules are evaluated on an ongoing basis and their actions are performed when necessary. Other rules are evaluated after certain events occur.
ALM Octane evaluates rule conditions and performs rule actions in one of two ways:
As users work, on an ongoing basis. ALM Octane checks to see if the conditions for activated rules are being met. When conditions are met, rule actions are performed. Most rules fall into this category (Make Read-only rules, Use Form rules, and so on).
If certain events occur. In addition to evaluating the conditions of activated rules to make sure the conditions are met, certain events must also occur for these rules' actions to be performed. These events include the creation of a new entity, deletion of an existing entity, or changing an existing entity.
Note: You do not have to specify a condition when defining this type of rule. The rules' actions can be performed when the event occurs without any other constraints.
Set Field Value rules. These rules change the value of a field as an entity is created or changed. These rules' actions occur as soon as the operation is initiated.
Send Email rules. These rules send an email if an entity is created, changed, or deleted. These rules' actions are performed after the user clicks Add or Save.
Alert User rules. These rules validate an entity when it is created, changed, or deleted, and after the user clicks Add or Save. These rules' actions are performed after the user clicks Add or Save.
The entity/context is considered valid if the condition is false. No alerts are sent.
If the condition is true, the user is alerted and updates are prevented.
Note: Moving an entity in the tree is not considered a change to the entity.
Activating and deactivating rules
By default, rules are activated when they are defined. To deactivate a rule after it is defined, select the rule in the Rule list and click OFF.
When creating rules that determine if a field is required or read-only, only one rule can be activated for a specific field.
For example, you cannot activate two rules on the field Priority, one making the field Priority mandatory and the other making the field Priority optional, at the same time. Both rules can exist, but they cannot both be activated.
If an entity meets the conditions of several rules, each of the rules' actions are performed on that entity in the order the rules are listed in the grid.
A rule checks if a defect is new (Edit mode=New) and if so, sets the input form to TheAddForm. This form lets users enter the basic information for a defect, without getting into details that are generally only known at a later time.
The next rule in the list checks if a defect is already in existence and being edited ( Not (Edit mode=New) ). In this case, the rule sets the input form to TheEditForm.
A third rule checks if the Priority for the defect is 1-Critical and if so, sets the form to TheCriticalForm. This form forces the specification of additional fields for explaining why this defect is critical. This rule contradicts the setting of the second rule, because as it is the last to run, its result is the one that is retained—even if the defect is not new.
If your organization has many rules, organizing them a certain way can help you see what's defined. You may find it helpful to organize your rule list according to how ALM Octane processes rules. This has no impact on when rule actions run, but it may help you see the big picture.
This order also most resembles the way ALM Octane processes the rules "behind the scenes."
List the rules that occur after a certain event:
Rules that change field values as an entity is being created.
Rules that change field values when an entity is changed or deleted.
Rules that send emails.
Alert User rules, which validate an entity and alert a user if there is a problem.
List all other rules. These are the rules that are evaluated and performed on an ongoing basis.
Tip: You are likely to have many rules that set different lookup lists and sub-lists to cover all scenarios. It's easier to read if these are grouped together at the end.
If you have rules defined for a shared space, and rules defined for workspaces associated with the shared space, it is important to understand which rules take precedence.
Workspace rules run first, before shared space rules run. If a shared space rule contradicts the actions defined in a workspace rule, the shared space rule takes precedence because it is run last.