Guidelines for Organizing Business Rules


Robert Eaman


In irAuthor, as with most software with structured logic, when you decide to implement a new application or a new addition to an existing application, you must make several decisions:

  • What will my rules do?
    • What are the intended inputs and outputs of these rules?
    • Are they tied to a specific data model?
    • Do they involve 1:1 or 1:∞ relationships (which involve using different techniques)?
  • How should I write my rules to do this? Apart from getting the logic right, should I strive for…
    • …efficiency?
    • …clarity?
    • …the ability to scale the rules easily as my requirements expand?
  • When will my rules do this?
    • As part of a manual process?
    • If automated, when will the entire rule application be called during the solution design?
  • Where do I need to put these rules? At what entity context, and within what kind of rule set structure for organizing?

Many of these questions ultimately lead to another, deeper question: Once I’ve completed a portion of my rules, how should they be organized? That’s the topic I intend to take on here with some broad guidelines I’ve accumulated from over 5 years of authoring rule applications for more than 50 customers.

Considerations for Logic Placement

There are a number of factors that will influence where you put your rules, but these general guidelines should help you with better rule application design. Keep in mind that there are exceptions to every piece of guidance listed below, but you should find this guidance useful.


ConsiderationWhere to Put LogicExceptions
Output: if your rules intend to change the values of one or more child entity fieldsAt the entity level of the child containing the changed fieldsIf your logic is limited in scope, consider placing it at a parent level instead
Business logicBusiness logic should be grouped by meaningful business processesOverlap between meaningful business processes may cause you to reevaluate this
Operational logicTo the extent practical, place logic which drives the flow of the rule application in its own rule setsIf your operational logic is limited or cannot be easily segregated, it can be included in business rule sets
Repeated, identical logicIn a separate explicit rule set; alternatively, use vocabulary templates in existing rule setsIf repeated logic can be either a) passed in as configuration data, or b) looked up from a table, consider those options
Minor utility functionsCalculated fields within the entity structure; alternatively, use vocabulary templates in existing rule setsIf this logic needs to be made more visible, move to rules and initialize variables in a language rule
Richer output messaging with multiple fields of dataA separate entity and rule sets related to that entityA structure like this might not apply to smaller rule applications
Validation logicA separate rule set(s) at the entity level of the fields being validatedMinor amounts of validation logic can and should be placed within business rules
Logic whose results will not be directly passed back in the rule application resultsUse variables in the rule set or temporary fields on the entity to store resultsn/a


Hopefully this list of general guidelines is helpful as you build out and refine your rule applications. If you have further or deeper questions about any of the topics or recommended above, please contact the ROAD Services team at Happy authoring!