This article covers:
- Types of business rules;
- Accessing business rules;
- Business rule information;
- Action section;
- Adding / removing conditions and exceptions;
- Conditions;
- Exceptions.
Business Rules in PPO allow an administrator to define and implement business processes by sending e-mail notifications, implementing workflows and enforcing business logic.
Types of business rules
PPO allows for 4 types of business rules to be configured:
Validation Rule: A business rule that is used to perform rule based validation of information captured on PPO by users. It therefore prevents the update from taking place based on the specified conditions. For more information on Validation Rules see the following article.
Send E-Mail: Based on a system event PPO will automatically send an e-mail notification. These business rules can be set up for any entity and can be customised to go out based on a specified set of conditions, allowing for flexibility and control. For more information on creating a Send E-Mail business rule see the following article.
Create Items From Template Project: PPO uses these business rules to automatically copy items from a template project when a new project is created. As an example creating default Tasks, Comments, Health Indicators or Documents when a new project is added. For more information on creating a business rule to Create Items From Template Project see the following article
Call Web Service: A business rule that calls a web service to perform some action based on a trigger event in PPO. This can be used for example to automatically create gate approval records when a Project is added on PPO. Please note that only the support desk can set up business rules that call a web service. For more information on creating a business rule that calls a web service see the following article.
Accessing business rules
If the user has access to Business Rules on the instance, the Business Rules menu item will appear under the Administration Menu. When you click on Business Rules, you will be directed to the Business Rules List page.
Like any list page in PPO the business rule list page can be filtered with the filter control. For further information on how to use the filter control see the following knowledge base article.
To edit an already existing business rule you can click on the record. Should you want to add a new business rule one would click on the Add button.
Business rule information
The business rule information section is the same for each business rule type and provides a description, indicates what triggers the business rule and also indicates what needs to happen when the business rule is triggered. Below is the list of fields required in the section with a brief explanation of each.
Description: The description describes the business rule in a few words and makes it easy to find on the business rule list page.
The entity this rule relates to: The entity on which you want the business rule to trigger. Examples would be a project, a task, a cost or a risk.
The events that should trigger this rule: The action used to trigger the business rule when being applied to the entity above. Sticking to the same examples would be when a project is added, when a task is edited, when a cost is added or updated and lastly when a risk is deleted
Is the rule active: The tick box allows one to temporarily deactivate the business rule without deleting the business rule.
Action: The action is used to specify one of the business rule types to be used as listed above. Note that the "Create items from template project" action is only available in respect of projects e.g. when a project is added.
Sort order: The sort order is used when there is more than one business rule configured for the same trigger event but the business logic requires that the business rules are executed in a specific sequence. An example may be that you want one validation rule to be performed before another.
Action section
Based on the business rule type or action selected, the details that need to be provided will differ. For more information on what details need to be specified, refer to the article for the specific type of business rule.
Adding / removing conditions and exceptions
Adding or removing a condition or exception is done at the bottom of the business rule with the Add button (adding a condition or exception) and the delete button (removing a condition or exception)
Conditions
Conditions allow you to further limit under which circumstances the business rule will be triggered. As an example a business rule that triggers on a project (the entity that triggers the rule) being updated (the event that triggers the rule) where the value of the phase is changing (Condition). There are 4 types of conditions that can be applied which are listed and described below:
Custom Conditions: This condition is used to trigger a business rule when a specific custom condition has happened. Please note that only the support desk can setup custom conditions.
Field values changed: This condition is used to trigger a business rule when a specific field value has changed. Note that this type of condition is only really applicable to an update.
New Values: This condition is used to trigger a business rule depending on how the field has been changed. The range of new values is specified by making use of a filter. To use this condition select the New values as a condition, then set up an applicable filter.
Old Values: This condition is used to trigger a business rule where the current / old values in a field are important. The range of old values is specified by making use of a filter. To use this condition select the Old values as a condition and then set up an applicable filter.
Exceptions
Exceptions are similar to a condition but just the inverse as it allows you to specify an exception to the conditions that trigger the business rule. It also differs from Conditions in that there is no Field values changed type and there is an additional User group type which allows updates from one or more user groups to not trigger the business rule. This is typically used for example to allow administrators to make changes that would be disallowed for other users.