Share this page

# Business rules

You can define business rules that trigger actions 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.

In this topic:

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

Back to top

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

Note: If you have more than 1000 business rules per entity per workspace, we recommend that you increase your 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 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.

Back to top

## Rules in shared spaces

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

Space | 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 Impact of rule order on how rules run.
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.

Back to top

Next steps:

- Design business rules

https://admhelp.microfocus.com Software Delivery Management 8942
Tips to improve your search results... OpenText™ Software Delivery Management Help Center OpenText™ Software Delivery Management Help 26.1 All View Local Help Center View Online Help Center Version: