A business rule is an action run on the server-side when a record is inserted, updated or deleted. Business rules are executed in a database transaction, irrespective of the interface used to initiate the transaction (user submitting a form, execution of a server-side script, REST request, execution of a Workflow Activity block). The action of a rule can be executed both on the current record and on other records.
Business rules can use scenarios to perform actions with records in the database. There are other options of the script actions available, such as client-side scripts and UI-actions.
Business rules are used for:
- changing values in the fields of a record that caused the rule to run when certain conditions are met;
- executing a server-side script of the rule;
- displaying a message to the client side;
- creating system events for sending e-mail notifications or running other server-side scripts;
- aborting transactions with the database.
To view all business rules navigate to System Definition → Business Rules.
To view the business rules related to a table, complete the steps below:
- Navigate to the list or form view of the table;
- Select Configure → Business Rules from the burger menu.
Business rules types
Depending on the business task to be completed, you can use one of the following types of business rules:
- before;
- after;
- async after.
Each type of business rules has its own run conditions.
Before rules run conditions:
- After record action start (insert, update, or delete).
- Before the system performs server updates (before the database transaction is completed).
After rules run conditions:
- After the system performs server updates (after the database transaction is completed).
Async after rules run conditions:
- After all business rules of other types (after all after business rules).
Async after business rules run after before and after business rules, so first, a user receives the form with all changes, and then async after rules run. Thus, using async after business rules, you can optimize system response time – use async after rules for resource-intensive scripts that take a lot of time.
The scheme below illustrates when before, after and async after rules run. All rules execute after a record action start (insert, update, or delete).
Process starts with a form action: if it is the update action, data source is the database, and therefore the record has the previous block. The previous block represents the form state before an action (form submission – insert, update or delete), and the current blocks represent the form state after the action is completed. Form submission can be performed by a user, script or REST API request.
Business rules creation
Role required: admin.
To create a new business rule, perform the steps below:
- Navigate to System Definition → Business Rules.
- Click New and fill in the fields.
- Click Save or Save and Exit to apply changes.
Business rules form fields
| Field | Mandatory | Description | ||||||
|---|---|---|---|---|---|---|---|---|
| Name | Y | Type in business rule name. | ||||||
| Table | Y | Select the table on which the business rule will run. | ||||||
| Description | N | Type in a brief action description. | ||||||
| Active | N | Select this checkbox to make the business rule active. | ||||||
| Inheritance | N | Select this checkbox to apply this business rule to all child tables of the table defined in the Table field. | ||||||
| Advanced | N | Select this checkbox to display the Script field and advanced settings such as the type of business rule (the When field in the When to Run tab). | ||||||
| When to Run tab | ||||||||
| When | N | Select the moment of business rule execution:
| ||||||
| Order | N | Specify the order of the business rule execution. If there are several business rules of the same type (before, after, async after), they run in the ascending order. This field appears when the Advanced checkbox is selected and the When field value is before or after. | ||||||
| Priority | N | Specify the importance of the business rule. This field appears when the Advanced checkbox is selected and the When field value is before or after. | ||||||
| Action Insert | N | Select this checkbox to execute the business rule when a new record is inserted. | ||||||
| Action Update | N | Select this checkbox to execute the business rule when a record is updated. | ||||||
| Action Delete | N | Select this checkbox to execute the business rule when a record is deleted. This field appears when the Advanced checkbox is selected. | ||||||
| Filter Conditions | N | A condition builder that allows using static and dynamic filters. After specifying a table in the Table field, all fields of this table will be available in the constructor. Use dynamic filter conditions like is (dynamic) or is not (dynamic) when composing conditional expressions to make your business rules more versatile. | ||||||
Action tab Action tab is not available for async after business rules. | ||||||||
| Set Value | N | Select a column and define the value you need.
| ||||||
Abort Action | N | Select this checkbox to interrupt the transaction (insert, update, or delete) when all conditions are met. It is a good practice to specify the reason of action abortion. Select the Add Message checkbox and type the text in the Message field. If no message is specified, the standard
If abort conditions cannot be set using the Filter Conditions field, you can use script with the setAbortAction and ss.addErrorMessage methods in the script. In this case, the Abort Action checkbox should be cleared. Keep in mind that when you use the | ||||||
| Add Message | N | Select this checkbox to display the Message text field if you want to show a message to a user when the business rule is performed. | ||||||
| Message | N | Enter the message you want to show to a user when the business rule is performed. The message is displayed as a flash message. Alternatively, to enable localization of the messages, use the values of the Source Message (source_message) records from the app category. See Localization and Multi-language Support to learn more. This field appears when the Add Message checkbox is selected. | ||||||
| Advanced tab | ||||||||
| Script | N | The action sequence that will be executed when a business rule is launched, previous and current variables are available:
You can call REM attributes in the business rules of before type. In this case, while the business rule is processed, you will get the current attribute values, before the transaction occurs. At the moment of triggering the async after business rule, the rule action is sent to the queue. Because of this, there may be an insignificant lag between the triggering of the business rule and execution of the action. The
This field appears when the Advanced checkbox is selected. | ||||||
Abort business rules
It is possible to perform business rules that terminate the follow-up actions and processes.
The abort business rules terminate the following processes: Business rules, Notifications, Approval Rules, etc.
See Approvals to learn more about approval rule rejection.
To make your business rule abort the follow-up processes, complete the steps below:
- Open a business rule record you need.
- In the When to Run tab, define the abort conditions.
- In the Action tab, select the Abort Action checkbox.
In the When to Run tab, check that the When field is set to before.
Click Save or Save and Exit to apply changes.
Out-of-the-box business rules override
If necessary, some out-of-the-box business rules can be overridden.
- For applications other than Simple it is sufficient to copy an out-of-the-box rule using the Make a copy action and deactivate the original rule. Then you can determine the required logic in the copy of the rule.
- For the Simple application the majority of the rules are delivered with Protection Policy = Protected, thus you can not simply deactivate them. However, the rules of the When=before type can be overridden by rules with the same start conditions of a higher order. For example, an out-of-the-box rule with the before type generates a value in a field. The order of the rule is 999. To change the value generation logic it is sufficient to make a copy of the rule using the Make a copy action, determine a specific logic and set Order = 1000. If the value in the field must remain unchanged, use the rule triggered by an Action Update event with the following script:
(function executeRule(current, previous = null /*not null only when action is update*/) {
if (previous) {
current.getValue('field_name') = previous.getValue('field_name');
}
})(current, previous);
Disable checkingPremium suggestions
