The add-on manages two rule categories:
'Business rules' are used to validate data and are executed using triggers or the data validation service.
'Permission rules' are used to manage user permissions and are implemented in compliance with the permission scheme applied to data and services.
There are four types of 'Business rules':
An 'Automated rule' can modify user data. This type of rule uses triggers set in tables to initiate execution and throws an error if it fails.
A 'Validation rule' cannot modify user data. This type of rule uses triggers or constraints set on tables to initiate execution and throws an error (when executed via triggers or constraints) or a warning (only when executed via constraints) if it fails. Depending on the configuration of constraint classes, record modification may be blocked if it fails.
A 'Manual validation rule' cannot modify user data. This type of rule is manually executed through the validation service. Depending on the success level, it validates, raises an error, or a warning.
A 'Table set rule' can modify user data. This type of rule is manually executed using the 'Execute rules' service.

An automated rule can modify data. The output value is Boolean and depends on whether the rule executed successfully or failed. This type of rule executes when triggered by the creation, modification or deletion of a record.
If the automated rule raises an error:
The trigger is interrupted.
An error message displays.
The transaction is aborted.
A validation rule is an assertion without any impact on the system and outputs a Boolean value depending on whether execution succeeded or failed. This type of rule can execute upon record creation, deletion or modification using a trigger or constraint on a field.
When the validation rule is executed by a trigger and raises an error:
The trigger is interrupted.
An error message displays.
The transaction is aborted.

When the validation rule executes via a constraint and raises an error, or warning:
An error message displays.
Depending on the constraint class configuration, record modification may be blocked.

A manual validation rule is an assertion without any impact on the system and outputs a Boolean value depending on whether execution succeeded or failed. This type of rule can be executed at the data set or table level.
Depending on the set level of execution, the standard validation service executes this type of rule in the following ways:
Execution at the data set level: the add-on executes all manual validation rules configured on each table included in the data set.

Execution at the table level: the add-on performs all manual validation rules applied to the selected table.

Any error and warning messages that are generated display in the standard validation report.

A table set rule can create, modify or delete data. Additionally, it can be an assertion without any impact on the data value. These rules return a Boolean value that indicates success or failure of rule logic execution.
You must execute table set rules manually using the 'Execute rules' service located in the 'Actions' menu of a data set, or table. Running the service at the data set level executes rules applied to all tables in the data set. When run at the table level, execution includes only rules applied to the current table. Note that if a rule is not designated as mandatory, you will have the option to include, or exclude it from this execution. The steps below briefly outline this process:
Run the 'Execute rules' service at the data set level.
Choose which rules you want to execute. Notice in the image below that the Name cannot be null rule's checkbox is grayed out. This indicates execution of the rule is mandatory. This behavior can be set in each table set rule's configuration options using the 'Mandatory' property.

After clicking 'Execute' a report shows the execution result including any errors or warnings.

There are two types of permission rules:
An 'Access permission rule' manages user permissions on data sets, tables or fields.
An 'Action permission rule' determines whether or not a user has permission to use the specified service.
These rules are called by the SchemaExtension class and the ServicePermission class. They are unknown at the trigger level.

An 'Access permission rule' manages user permissions on a node, namely a data set, table or field. This type of rule determines whether or not the node is Hidden, Read-Only or Read-Write for a given user.
An 'Action permission rule' manages service permissions. This type of rule controls whether or not the given service can be used in the current context.