There are many occasions when you need to set the value of a field based upon the value of one or more fields. Contemporary products typically achieve this via modifying the programming language. ExtraView allows you to set field values using this administrative feature. Field values can be set at different points in the process.
Business rules are also used to link together values from different business areas, creating relationships between different Business Areas. For example, a relationship can be created to populate a set of fields on a field within a Customer Issue business area, based upon the value of a customer name created in business area that contains a list of customers.
Email rules can also be created, giving fine control over who will receive email upon the creation or updating an issue. The default notification scheme in ExtraView will send email to any user whose name appears on a form, and to members of any interest list. Email rules can complement or replace this arrangement, and give precise control over the notification process. For example, you might want to send notification to a user, only when the Status changes to a specific value, or if the Status changes. Email rules are only applied after you submit an issue to be inserted or updated, and therefore the names that are added to the mailing list that is displayed on the add and edit screen will not display these names.
Note that ExtraView’s inbuilt notification rules remain active, and users will be notified as normal, unless you set the behavior setting named SUPPRESS_STANDARD_EMAIL_LIST to a value of YES. This can be found in the Email Settings administrative function.
Rules may be defined as either global in scope, or to only be executed within a specific business area within your installation. Global rules have precedence over rules defined in a specific business area. Therefore, rules in a specific business area are executed first, and then the global rules are executed. This ensures that rules defined with a global scope will be the last to be executed. There is no checking of whether rules in a specific business area may be in conflict with one or more rules in the global area. It is the administrator’s responsibility to ensure that rules work together. To avoid the possibility of a conflict, you may set a policy that no rules will be created as global, and are therefore all local in their scope. When the administrator views the list of business areas, they will only see those to which they have permission, thus enforcing the privacy of rules set in a business area to which the current administrator does not have permission.
Automatic Backup of Rule Updates
As with all metadata changes, when you update the rules an entry is made in the System Log of the event. In addition to the usual information, a copy of the old rules text is also placed in the System Log. You may copy the text from the System Log and paste it back into the rules text area if you need to restore a prior set of rules.
If the rules text is greater than 3,800 characters in length, there is insufficient room to hold all the information in the System Log, so a partial entry is made there and the complete rule text is written to the application server log file.