Business rules

You can define business rules that trigger actions in ALM Octane when certain conditions are met.

This topic provides an overview of business rules, planning considerations, and an explanation of rule hierarchy. For details on how to create rules, see Design business rules.

Introduction

Rules contain an action and usually one or more conditions.

You set the action that should occur when the conditions are true.

Actions

Examples of actions include making fields required, making fields read-only, and setting a default value for a field.

Conditions

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.

Rules are created per entity type.

For certain entity types, ALM Octane provides pre-defined rules. These control basic behaviors, such as assigning tests to their owners.

Sharing rules between spaces

Rules can be defined on the shared space level and on the workspace level.

In isolated spaces, you cannot define rules on the space level, only on its individual workspaces.

Rule created in the shared space run in its associated workspaces. Rules created in a workspace are applied in that individual workspace only.

You can define rules for individual workspaces. The rules are applied in that individual workspace only.

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?

Plan

Plan out the rules you need and their order.

You can combine several actions into one rule, if the actions all share the same condition. This can improve performance.

Example: Using just one rule, you can set several fields to read-only. Similarly, using a different rule, you can make several fields required.
Maybe 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 important. Later rules override the actions of earlier rules.
Enterprise Edition: Determine if the rule should be defined on the space level (shared) or on the workspace level.
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.

When are conditions evaluated and actions performed?

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 (for example Make Read-only rules, or Use Form rules).
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.

Examples include:
- 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.

Does the order affect how the rules run?

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.

Example:

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.

Organizing the rules logically in the grid, can you review your list of rules. 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:
1. Rules that change field values as an entity is being created.
2. Rules that change field values when an entity is changed or deleted.
3. Rules that send emails.
4. 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.

Do shared space rules or workspace rules take precedence?

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.

Next steps:

Design business rules