One definition of a rule is where “data meets process”.
In the rules it inevitable that there will be elements of data, usually primary keys, as well as “code” in the forms of algorithms and decisions.
The data in the rules is referred to here as Metadata.
There is no single systematic approach to how best to handle the inclusion of metadata in the rules.
If, for example, the organisation is entirely conversant with product codes, the rules like:
If product-code == '12345-67890' then ....
are appropriate. The obvious disadvantage is that the numeric code above has to be manually maintained – it is not connected or automatically synchronized with other systems.
Some rules engines have the facility to allow the elements in the rules to be linked to external systems, especially databases. These facilities have to be used with caution, otherwise day-to-day data manipulations can invalidate rules.
In any case, the best course of action is to subject the metadata to analysis: establish with appropriate tools (use-cases usually) the life-cycle of the metadata and implement the systems accordingly.
Note that deep connectivity with other systems always has the potential to undermine the top benefit of a BRMS: rapid implementation.
.