Design business rules

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

For an introduction to business rules and their principles, see Business rules.

In this topic:

Overview

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.

Create a rule

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 in one of the following ways:

   • Create a brand new rule: Click the Add Business Rule button . Select an action and condition. For details, see Rule actions and Define conditions.

   • Create a new rule, based on an existing rule: Select an existing rule and click the Duplicate button . Click the Edit button , and modify the rule as required.

Back to top

Rule actions

The first step in designing a business rule is determining the action that the business rule initiates. For details of the possible actions, see Business rule actions.

Back to top

Define conditions

Define the conditions on which the business rule action is activated. If no condition is defined, the business rule is always activated.

You can formulate complex conditions for rules that include several conditions separated by AND or OR operators.

To define a condition:

1. Click the Condition tab.

2. Select a field on which to base the condition, or a special circumstance.

   Circumstance	Details
   Edit Mode	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: (Edit mode ≠ New) You can further refine the rule by specifying a value such as Duplicate or Split. For example, you can create a rule to clear certain fields when an entity is duplicated or split.
   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: Counts 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. Click OK. Counts of items related to other entities Find features with tags that I created: Select the Feature entity. Select Tags count for the Field value. Click the Filter button and then Add Filter. Select Author > Equal to > Me. Select the > operator. Enter the value 0. Click OK twice. Update an item based on counts of related items You can set field values when a related entity changes by creating a condition based on the counts of a related entity in a Set Field Value rule. The following counts are particularly useful:  children count (for features) child task count (for user stories) Update the phase of a user story to Done if all its tasks are completed: Select the User Story entity. Select Child task count for the Field value. Select the Filter operator. For details, see Design business rules. Select Phase > = > In Progress, New. Select the = operator. Enter the value 0. Click OK twice.

   Certain fields allow you to apply a cross-field condition to a business rule based on a field with a relation to the entity. Entities with these capabilities are indicated by the Cross-field icon . You set a cross-field condition just as you would set a cross-field filter.

   

   In the following example, the condition was set to any release preceding 06/11/2020.

   

   Note: The cross-field condition only applies to single reference fields, such as release, owner, and phase; it does not apply to multiple reference fields, such as application modules and tags.

3. Select an operator.

   Different operators are available for different field types.

   The operator list is divided into two: Current and Original.

   • Current: Evaluates the current value of the field when the rule is triggered.

   • Original: Evaluates the value of the field at the time that the item was retrieved.

   The following special operators are available, depending on the field type.

   Operator	Details
   contains	Checks if the field contains the value you select from a list. The operator checks many:one relationships.
   include	Available for: Current User Role field. Checks if the user is assigned to one of the selected roles. The operator checks 1:1 and Equals relationships.
   contains any/includes	contains any checks many:many relationships. includes checks 1:many relationships. If you choose contains any or includes, the next operand choice should either be Current User Teams and/or actual team names. These conditions can be useful when you want to make different permissions for users within specific teams.
   is empty	Checks if the field is empty.
   is modified	Checks if the field is modified from its original value.

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

   As you build the condition, a textual representation of the condition is displayed in the Description box.

   After you save rules they are automatically run.

   Note:  

   • If you are using an Enterprise license, you cannot set the user field for all workspaces in a shared space. This capability is blocked since each workspace may have different users.

   • Conditions can evaluate to false if a field is encountered in a rule definition that cannot be processed 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.

Back to top

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.

Back to top

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:

• Trigger webhooks for other applications
• Forms
• Workflow rules
• Rule examples