Relavent to ShareDo v7.7 and later

Introduction

Business rules in ShareDo evaluate conditions and arrive at a result that is either true or false. The result is then used to “do something”, such as running a specific workflow step or deriving an allocation rule. Business rules are made up of data (derived from its context) and operators such as AND, OR, and NOT; these can be combined to build complex logic.

The ShareDo rules engine has been rewritten for version 7.7. This new business rules solution comprises the following elements:

• A new user interface and better experience for creating and maintaining rules.
• The migration of legacy matching rules to this new model and the new model for transient data matching to be used on aspects and option sets.
• A consistent user interface pattern for interacting with rules throughout the system.
• Enhanced ability to visualise the rules that are defined within their different contexts e.g. work items, templates etc.

Examples of rules include:

• Given this user ID, does the user have permission X?
• Given this user ID, is the user supervised?
• Given this work item, is it a task (including derived)?
• Given this work item, is the client Acme?

Rules can be as simple as single checks or much more complex – multiple evaluations to arrive at true/false answers to questions like:

• Given this work item, is it a matter, AND the subtype is RTA, AND the client is Acme?

The different parts of a rule

To define a rule, we need the following:

• A data context to run against.
• Different types of evaluations.
• Logic combinators.

Data context

The data context provides the starting point for determining what questions can be asked using evaluation types. Each rule is defined as applicable to a context type. For example, “this rule can be run against a work item or a participant”.

In ShareDo, rules are run against different contexts, such as:

• A work item.
  • An instance of a work item as identified by its ID.
• A Participant.
• An ODS user.
  • An instance of a user record as identified by its ID.
  • Could also be the current user (ambient environment).
• An ODS person.
  • An instance of a person, as identified by its ID.
• An ODS organisation.
  • An instance of an organisation, as identified by its ID.
• A Document template.

The Data Context defines both the Data Composer fields that are available for use within the rule; together with the types of rules available. For example, these are the available rules when the context is set to Work Item:

Additional context parameters

Ideally, any rule is run against a single input parameter. As noted above, running a rule intended for a work item requires passing in a work item ID. However, there are some edge cases where one or more evaluation types require additional parameters.

One such example would be the authority limit evaluator. In this, the rule would be a work item rule as it will sum up the total offer values under a matter work item and then compare this to the authority limit set against a user. In this case, we are asking the question of the work item (that’s the context) but need to add to that the user ID we want to check limits against (it won’t always be the current user, especially when run from a workflow, where there is no current user).

It may be possible to change this to something more context-aware without the need for additional parameters—e.g., validate the authority limit of the holder of the matter-owner role on the work item or something similar. However, the ShareDo rules engine had the ability to add parameters to rules built-in. These additional parameters are declared and added to the context, and the evaluation types can then use them as they see fit. 

Different types of evaluations

At the most basic level, the rules engine combines data (i.e., data from the data composer) and operators to produce a result. A common use for this is determining whether a field has an expected value. For example, in a Document Generation context, an evaluation may be “Is the matter's jurisdiction Scotland?”.

The available evaluator types are listed in the following table:

Logic combinators

This is simply the grouping of evaluators in a rule into AND/OR blocks. For example: 

[evaluation 1] AND ([evaluation 2] OR [evaluation 3])
OR
[evaluation 4]

Which would return true if these combinations of evaluators returned true:

• evaluation 1 AND evaluation  2
• evaluation  1 AND evaluation 3
• evaluation 4

Evaluation of transient data

The concept of a rules engine so far has concentrated on the idea that data is available for comparison. This isn’t always the case though.

Typical uses of a rule will be to ask a question about a piece of data that exists, but there are other areas where it may be necessary to make decisions based on a transient state that hasn’t been saved yet.

Examples are:

• Option sets – changing the set/values available based on some other inputs on the same screen. As the other inputs change, the available values need to change based on rules being fulfilled. There is no data to load in this circumstance – we may add a new work item for example.
• Aspects – showing and hiding different data capture again based on the changing of data on the same screen before it has saved. For instance, I may have a custom form to show if the client is acme – this aspect is on the same blade as a participant picker for the client role. Ideally the form builder would show/hide if I change the client, despite no data being available in the database as yet.

Transient evaluation is primarily a UI-centred feature and can be used to run rules against newly created entities (for example, a new work item) or changes that have not been saved yet (for example, when a user changes the work item's subtype). Evaluation of transient data has been built into the new rules engine.

Areas of ShareDo where business rules are used

ShareDo uses business rules in the following areas:

In most areas where rules are used to control the display, a “mini-canvas” appears in the blade:

Additional abstractions 

While the rules engine itself evaluates to a Boolean result, additional abstractions are then layered on top of this to answer domain-specific questions. A good example would be allocation rules, where, given a work item context, we ask the engine, “Who should I allocate this to,” and the result is the ID of a user or team.

This is not to be confused with the underlying rules engine. This is an additional abstraction (both UI and technically) that layers on top of the Boolean rules engine. The rules engine defines “Is this work item a matter?” and “Is it of type RTA?” – which evaluate true/false. The allocation rules engine then defines answers to the specific question using these rules e.g.:

• If Rule 1 = true – return “RTA team”
• If Rule 2 = true – return “Matter team”
• Otherwise – return “Default team”

While this is another layer on top of the rules engine, it is presented within the same interface used to manage the underlying rules. For example, when adding to the rules engine, one might add a new rule or a new allocation rule—a new rule would allow defining the conditions to be evaluated, and a new allocation rule would allow the composition of those rules to arrive at an outcome.