Business rules

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

Introduction

Rules contain an action and usually one or more conditions.

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

Component Description
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.

Some entity types have predefined rules. These control basic behaviors, such as assigning tests to their owners.

Plan

Plan the rules you need and their order.

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

  • Several rules might be 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.

Rule hierarchy

If an entity meets the conditions of several rules, each of the rules' actions are performed on that entity in the order that 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 rules are processed. This has no impact on when rule actions run, but it may help you see the big picture.

This order also most closely resembles how the rules are processed "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.

Shared space rules

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

Level Description
Shared space

Rules created in the shared space run in its associated workspaces.

Shared space rules are evaluated after all the workspace rules. For details, see Rule hierarchy.
Workspace

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

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.

When defining business rules at the space level, you can use fields that might have workspace-specific values. In the business rule, the available values and operators for such fields are generic, such as '[current user]', 'is empty', 'is modified'. Such fields include: User fields, Tags, Team, Environment, and reference fields (such as Feature and User stories).

Create a rule

A business rule is made up of two main components: an action and a condition. The action is performed automatically when the condition is met. You can define business rules with only an action and no condition. This can be useful, for example, for setting fields as always required.

When you create a rule, you must define the action that it triggers, and then set the conditions (optional).

To create a rule:

  1. Open the Settings menu, click Spaces, and select a space or a workspace.

  2. Click Entities and select the item for which you want to create a rule.

  3. Click Rules.

  4. Create a new rule from scratch or based on an existing rule:

    • Click the Add Business Rule button .

    • Select an existing rule and click the Duplicate button . Click the Edit button , and modify the rule as required.

  5. Select an action. For details, see Business rule actions.
  6. Define condtions. For details, see Business rule conditions.

Activate and deactivate 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. Both rules can exist, but they cannot be activated simultaneously.

Rules for manual test runs

Consider the following when designing rules for manual test runs:

Rules triggered by manual test run creation

Rules that are defined to be triggered when manual test runs are created, are not triggered in cases where runs are created in bulk. This applies when either running or planning a group of tests or a test suite.

To ensure that the rules are triggered in these cases, define the rules to run also when the entities are updated. This way, the rule actions are activated when the testers update the runs, and they receive relevant alerts and required fields.

Rules for Gherkin test runs

A manual run entity can represent either a manual test run or a manual run of a Gherkin test.

To make sure both types are covered in a rule for a manual run, define the conditions in a way that refers to both types. For example, show an alert in case:

Phase[Manual]=not_reviewed OR Phase[Gherkin]=not_ready

Next steps