Follow

Business Rules

This article covers:

Business Rules

PPO allows users to set up Business Rules from the front-end of the solution. These rules include actions such as preventing an update if certain criteria aren't met (Validation Rules) and the sending of e-mails based on trigger events in PPO (Send E-mail). Users also have the ability to view all the web services that have been set up on their instance. 

To make use of this functionality the PPO administrator must have access to the Business Rules icon on the Administration menu item.

KB_businessrules_1.jpg 

1. Call Web Service

PPO has a collection of web services that come standard as part of any PPO instance. These web services can be called to retrieve information for use in a third party application or can be used to update PPO entries based on information from a third party application.

These web services are available at no cost to all clients, subject to reasonable use restrictions. All web services are secure and require the caller to first authenticate him or herself before being able to perform any retrieval or update of information.

For a full list of the available web services, please browse to the following address:
http://www.ppolive.com/test/webservices/integration.asmx.

Web service based integration is best suited to synchronous (i.e. real time) integration where the client has sufficient skills to implement the business logic around the integration.

For more information on using web services through the API, see the following FAQ.

PPO allows users to view the web services that have been set up by accessing the Business Rules section under the Administration menu item.

Please contact the PPO support team should you require any web services to be set up or amended. 

KB_businessrules_1.jpg 

The following information is provided per business rule:

FAQ_businessrules.png 

1. Description: This is a description of the business rule.

2. The entity this rule relates to: The applicable entity.

3. The events that should trigger the rule: This indicates whether the rule is triggered on add, update or both.

4. Is the rule active?: This indicates whether the rule is active or not.

5. Action: Indicates this is a "Call Web Service" type business rule.

6. XSL transformation of event XML: This box contains the logic code that calls the required web service.

7. E-mail address to receive error notifications: This is the e-mail address that will receive all error notifications.

8. Conditions: This section shows the conditions under which the web service will be called. If the conditions section is empty, the web service will be called for all updates of the applicable entity.

9. Exceptions: This part of the rule shows the exceptions to the rule, i.e. events for which the rule will not be triggered.

10. Summary: A summary at the end of the page will explain the business rule that has been specified.

KB_businessrules_4.jpg

2. Send E-mail

PPO includes an e-mail events model which allows the application to generate automatic e-mails based on system events. System events include the adding, editing and deleting of entity records such as Issues, Risks, Tasks, and so on. E-mail events can be set up for any entity in PPO and can be customised to go out only for a specified set of conditions, allowing for flexibility and control.

Note: To enforce PPO's security model, e-mail notifications are only sent to people who have an active user account on PPO. All e-mail notifications adhere to PPO's user group access settings, ensuring that no unauthorised information can be accessed via e-mail.

Customers who understand these risks but still want to send notifications to non-users may elect to do so by going to Administration >> System Configuration and enabling the sending of e-mails to non-users (this is found under Technical Settings).  Note that only the user designated as the Key Client Contact will see or be able to change this setting.

For more details about the implications of allowing e-mails to be sent to non-users, see the following FAQ.

To set this up click on the Add Business Rule icon and complete the following information:

KB_businessrules_5.jpg

1. Description: Provide an applicable description for the business rule.

2. The entity this rule relates to: Select the applicable entity.

3. The events that should trigger the rule: Select whether the rule should be triggered on add, update or both.

4. Is the rule active?: Specify whether the rule should be active or not.

5. Action: Specify the "Send E-mail" action.

6. E-mail Subject: Enter the desired e-mail subject.

7. E-mail Body: Enter the text that should appear in the body of the e-mail. 

Note: The e-mail subject and e-mail body can be customised to include information like the Project name, Task / Issue / Risk title, Priority, etc. For details on how to set this up, see the following FAQ

8. Data Fields: Click on the data fields line to see a drop down list of the fields available for the e-mail notification. Select the fields that should be included, then click on the Apply Changes icon.

KB_businessrules_6.jpg

9. Recipient Fields: Click on the recipient fields to see a drop down list of the recipients available to send the e-mail notification to. Select the recipients who should be included, then click on the Apply Changes icon. 

10. Conditions: This section allows you to specify which conditions will cause the e-mail to be sent. As with calling web services (explained above) PPO allows for a wide range of conditions to be specified using three types of conditions, in conjunction with three exceptions (discussed in the next section of this article): Field values changed; New values; and Old values.

These conditions are used as follows:

  • Field values changed. This condition is used to fire an e-mail notification when a specific field value has changed. This is used to set up triggers that will only be fired if the value in a specific field(s) is changed.

To use this condition select the Field values changed condition. Then select the applicable field(s) from the drop-down list in the Values column and click on the Apply Changes icon.

KB_validations_step100.png

This business rule will then only be fired when these fields are updated, taking into account any exceptions specified (see the next section in this article).

  • New Values. This condition is used to set up an e-mail notification 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 condition, then set up an applicable filter.

KB_datafields_step113.png

For example, to set up an email notification to go out when an action status is changed to closed, the filter to set up will be the following:

KB_businessrules_7.jpg

This e-mail notification will then be sent when the action status is set to closed.

  • Old Values. This condition is used to prevent an update 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 condition, then set up an applicable filter.

KB_validations_step102.png

For example, to set up a business rule to send an e-mail whenever an update is made to an active project, the filter to set up will be the following:

KB_validations_step103.png

The e-mail will thus be sent every time an update is made to a project with an active status, regardless of whether the status changes during the update. 

9. Exceptions: This part of the rule allows you to award an exception to the rule to certain user groups, certain new values and certain old values. PPO allows for a wide range of business rules to be specified using the three conditions (explained above) in conjunction with these three exceptions: Field values changed; New values; and Old values.

KB_validations_step104.png

These exceptions are used as follows:

  • User Group. This exception is used to allow a whole user group to be able to circumvent the sending of an e-mail notification.

For example, to disable e-mail notifications if the PPO Administrators user group edits an Issue, the exception will be set up by selecting the User Group exception and selecting the PPO Administrators from the Values drop down list:

KB_validations_step106.png

This exception will allow any user in the PPO Administrators user group to be excluded from the rule specified in the conditions section.

  • New Values. This exception is used to exclude certain updates from sending e-mail notifications, based on a range of new values specified during the update. This range is specified by a filter.

To use this exception rule, select the New Values exception, then specify an applicable filter.

KB_validations_step108.png
  • Old Values. This exception is used to exclude certain updates from sending an e-mail notification, based on a range of existing values. This range is specified by a filter.

To use this exception rule, select the Old Values exception, then specify an applicable filter.

KB_validations_step110.png 

3. Validation Rules

PPO uses validation rules to verify updates in terms of the rules supplied. If an exception occurs when a record is submitted, the user is redirected back to the edit page and an appropriate validation message is displayed. The user then has the opportunity to correct the problem and try to submit the item again.

Validation rules can be set up to prevent users in certain user groups from editing specified fields, changing fields to precise values and enforcing required fields under specific circumstances, among other rules. For example, validation rules can be set up to only allow the project office to change the phase of a project; set the Project Manager field to be required when a project is in Execution; force the project to start in the Proposed status, to disallow project team members to update planned start and end dates of Tasks; or to only allow the project to be made inactive when it is in the Benefit Realisation stage. 

FAQ_businessrules_step1.png

To add a validation click on the Add Validation Rule icon. The page that opens shows the following sections:

kb_validationrules_step1.png

1. Validation rule information: This section shows whether the rule you are implementing is active (Yes / No); the entity the rule will be applied to (any entity in PPO); the event that will trigger the validation (can be on add, on update (edit) or on both add and update of a record in the entity selected above) and an error message that will display when the rule is not passed.

kb_validationrules_step2.png

Validations can be implemented on add or on update or on both. You can therefore specify rules that should only be applicable when a record is edited, allowing the user to specify the field values when adding a record.

2. Conditions: This section allows you to specify which conditions will cause the validation rule to prevent the update and show the specified error message. PPO allows for a wide range of validation rules to be set using three conditions, in conjunction with three exceptions (discussed in the next section of this article): Field values changed; New values; and Old values.

KB_datafields_step112.png

These conditions are used as follows:

  • Field values changed. This condition is used to prevent a change on a specific field. Examples of validation rules that will make use of this condition are: only the project office is allowed to change the Project Classification field; only the project manager can set the issue status; only an administrator can edit the health indicator title field.

To use this condition, select the Field values changed condition, then select the applicable field(s) from the drop-down list in the Values column and click on the Apply Changes icon.

KB_validations_step100.png

This validation rule will then prevent the update on these fields, taking into account any exceptions specified (see the next section in this article).

  • New Values. This condition is used to prevent an update depending on the value the field is changed to. The range of new values is specified by making use of a filter. Examples of validation rules that will make use of this condition are: the project must start in the proposed status; the project can only be made inactive in the benefit realisation stage; the project status cannot be set to cancelled during the closure stage.

To use this condition, select the New Values condition, then set up an applicable filter.

KB_datafields_step113.png

For example, to set up a validation rule to prevent the adding of a project if it's status is not proposed, the filter to set up will be the following:

KB_validations_step101.png

This validation rule will then prevent the adding of a project, taking into account what the values of the specified field will be after the update (new values) as well as any exceptions specified (see the next section in this article).

  • Old Values. This condition is used to prevent an update where the current/old values in a field are important. The range of old values is specified by making use of a filter. Examples of validation rules that will make use of this condition are: only the project administrator can change the project status from active to any other status; only the project manager can change the issue classification if the current classification is "confidential".

To use this condition, select the Old Values condition, then set up an applicable filter.

KB_validations_step102.png

For example, to set up a validation rule to prevent the users from changing the project status from active to any other status, the filter to set up will be the following:

KB_validations_step103.png

This validation rule will then prevent the editing of a project, taking into account what the value of the specified field is prior to the update (old values) as well as any exceptions specified (see the next section in this article). 

3. Exceptions: This part of the rule allows you to award an exception to the rule to certain user groups, certain new values and certain old values. PPO allows for a wide range of validation rules to be specified using the three conditions (explained above) in conjunction with these three exceptions: Field values changed; New values, and Old values.

KB_validations_step104.png

These exceptions are used as follows:

  • User Group. This exception is used to allow a whole user group to be able to circumvent the validation rule.

For example, to allow the PPO Administrators user group to edit the fields specified in a changed fields validation rule (as used in an example above) the exception will be set up by selecting the User Group exception and selecting the PPO Administrators from the Values drop down list:

KB_validations_step106.png

This exception will allow any user in the PPO Administrators user group to be excluded from the rule specified in the conditions section.

  • New values. This exception is used to allow an update if the new values fall within a specified range. This range is specified by a filter.

To use this exception rule, select the New values exception, then specify an applicable filter.

KB_validations_step108.png

For example, to allow an update on the project status field that would have otherwise been prevented by a rule (using the example above where the project status could not be changed from active to any other status), an exception can be added that allows the update if the new value (value after the update) is "rejected". To set this up, select the New values exception, then specify the filter as below:

KB_validations_step109.png

This exception will allow the user to change the project status from "Active" to "Rejected", even though the condition of the rule prevents the project status from changing once it's active.

  • Old values. This exception is used to allow an update if the old values fall within a specified range. This range is specified by a filter. 

To use this exception rule, select the Old values exception, then specify an applicable filter.

KB_validations_step110.png

For example, to allow an update on the project category field that would have otherwise been prevented by a rule (for example, that the project category field may not be edited after the project is added) an exception can be added that allows the update if the old value (value before the update) is "unspecified". To set this up, select the Old values exception, then specify the filter as below:

KB_validations_step111.png

This exception will allow the user to change the project category only if the current/old value is "unspecified", even though the condition of the rule prevents the project category from being edited.

4. Summary: This section shows you a summary of the rule that will be applied.

kb_validationrules_step5.png

The Summary is also a useful tool to use while setting up the validation rule. It allows the user to see exactly what is being applied. This can further be enhanced by specifying appropriate filter names when using old values / new values conditions and exceptions.

For example, the filter names used in the following validation rule clarify what will be applied:

KB_validations_step112.png

Deleting a Validation Rule

There are two options available when removing a validation rule:

1. The rule can be deleted. This can be done by clicking on the Delete Validation Rule icon from the Validation Rule >> Edit page.

A validation rule will no longer be accessible after it has been deleted. If a similar validation rule is required in future, it will have to be set up again from scratch.

kb_validationrules_step8.png

2. The validation rule can be made Inactive. This means the validation rule will still exist on the Business Rules page, it will just not be applied. This means the validation rule can be made active again when required.

kb_validationrules_step7.png
Was this article helpful?
2 out of 2 found this helpful
Have more questions? Submit a request
Article is closed for comments.
Start a 30 Day Free TrialClick ClickNo Credit Card and No Obligation
Powered by Zendesk