The “Rules Engine” tool provides the ability to define business rules in Synergy Enterprise. With many customers of this tool, they are using Proactive, rather than Reactive for the Actions selected for the Requests or Card.
Rules can be made for inclusion within workflow request or cards in Synergy. As an example, required fields in a request or a card may be dependent upon the value entered into another field. Proactively, the request or card cannot be saved until the fields are entered. In the past, an Event Manager trigger would notify the resource that fields were missing and that the request / card would need to be reopened. This results in a time lag of correct information and opening a request or card in a second process.
Rules created will support checking Synergy data but also will support checking on criteria from your ERP software.
Based on the rules that have been created, different message types can be displayed or actions can be triggered.
The different types of messages that can be shown to the user are:
- Error message, when the rule is executed and the rule result is positive the user will be shown an error message on the specified application and the user will not be able to continue.
- Warning message, when the rule is executed and the rule result is positive, the user will be shown a popup when where the options ‘continue’ and ‘cancel’ are available. When choosing ‘continue’ the data will be saved. When choosing ‘cancel’ the data will not be saved and the user can change the input.
- Access denied, when the rule is executed and the rule result is positive the user will be shown a message access denied and the data can’t be viewed.
- Note, when the rule is executed and the rule result is positive the user will be shown a popup when the application is opened. This could be a message to inform the user the take a certain action.
The messages shown to the user can be setup at the rule maintenance and supports formatting. This gives the option to add hyperlinks in the message. The message also allows for ‘merge tags’ so that the message can contain data which is retrieved from the database and is not static.
The different types of actions that can be triggered are:
- Action: Create, when the rule is executed and the rule result is positive it will allow creating data. For example based on a completion of a request automatically an item can be created. Another example would be to create additional workflow/request tasks based on the rule, this will allow for adding additional persons to the workflow so they also can take action on the workflow.
- Action: Update, when the rule is executed and the rule result is positive it will allow updating data.
- Action: Delete, when the rule is executed and the rule result is positive it will allow the removal of data.
- Scripting, this will give you the option to add javascript to the standard pages. Similar as you can do in the workflow request type setup when using a section. This gives you the opportunity to make some simple modifications to the pages without requiring any SDK or Configurator knowledge or expertise. As long as you are familiar with javascript / jquery, you can make some simple modification in a page.
Rules can be built as a single action or with multiple relationships. These types include:
- Simple Formula, where the rules will check one set of criteria. Think of extra validation on one or more fields where based on one check / rule the user will be shown an error, warning or message.
- Parent /Child, where the rules also can be a full set of rules which are linked together via a parent child structure and will be executed starting at the first rule. The process will go through all the child rules and based on the outcome in each step it will stop or go to another rule until the last step is reached. This scenario could be applicable for a purchase order approval process. Where based on amount, supplier, certain products or other data, different approval flows can be started.