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 do not 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.

Plan

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

Note: If you have more than 1000 business rules per entity per workspace, we recommend that you increase your ALM Octane server heap size to 12 GB, and consider adding another node to support this configuration.

Back to top

Impact of rule order on how 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, you can 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."

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

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

Back to top

Rules in shared spaces

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

  • Shared space: Rules created in the shared space run in its associated workspaces.

  • Workspace: You can define rules for individual workspaces. Rules created in a workspace are applied in that individual workspace alone.

Shared space rules are evaluated after all the workspace rules. For details, see Impact of rule order on how rules run.

Workspace rules do not impact shared items. For details, see Shared items in workspaces.

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

Back to top

Next steps: