Follow

Business Rules - Validation Rules

This article provides detailed information about the Validation rules in PPO

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.

Accessing the validation rules

To view a list of validation rules that have been setup on your instance, access Administration >> Business Rules and select “Validation Rule” from the Type drop-down list, as shown below:

Accessing_the_validation_rules.jpg

Adding a validation rule

To add a validation rule click on the “Add Business Rule” icon and complete the following information:

Add_Business_Rule.jpg

Business Rule information:

  1. Description:Provide an applicable description for the validation rule. Try and stick to a certain naming convention that works for you, for example add the “Entity Type” first and then the event trigger, so it’s easy for your to identify the validation rule that has been setup, for example Comment – Cannot edit title, which is the validation rule that has been setup for preventing users from changing the comment titles.
  2. The entity this rule relates to:Select the applicable entity from the drop-down list.
  3. The events that should trigger the rule:Select whether the rule should be triggered on add, update, add and update, or on delete.
  4. Is the rule active?:The Active checkbox is by default selected when a new business rule is added.
  5. Action:Specify the "Prevent Update" action.
  6. Sort Order: You are able to specify the order in which the validation rules need to happen.

Action information:

The message to display field is used to capture the “error” message that the user will see when they try and update the field, which is protected by the validation rule that has been setup.

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 four conditions, in conjunction with four exceptions (discussed in the next section of this article): Custom Condition; Field values changed; New values; and Old values.

Custom_Condition.jpg

These conditions are as follows:

  • Custom Condition: This condition us used to prevent a change on a specific field, based on a custom condition that has been setup.
  • 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 officeis 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 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.

Field_Values_Change_Condition.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.

New_Values_Condition.png

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

The_project_status_is_not_approved.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.

Old_Values_Condition.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:

Project_Status_is_Active.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).

Exceptions:

This part of the validation 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 four conditions (explained above) in conjunction with these four exceptions: Custom Condition; New values; Old values and User Group.

User_Group_Exceptions.jpg

These exceptions are used as follows:

  • Custom Condition.This condition us used to prevent a change on a specific field, based on a custom condition that has been setup. An example of a custom condition on a validation rule is to prevent an update of document approvals in review, except if the user belongs to the PPO Administrator group. For assistance in setting up custom conditions on your instance, please log a support call and the PPO support team will gladly help you.

Exception_Custom_Condition.jpg

  • 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.

Exceptions_New_Values.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:

Project_status_is_changed_to_rejected.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.

Exceptions_Old_Value.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:

Project_Category_is_Unspecified.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.

  • 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:

Exceptions_User_Groups.png

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

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

Summary.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:

Summary_for_project_manager.png

Editing a validation rule

If you would like to edit an existing validation rule, you only need to click on Administration >> Business Rules and select “Validation Rule” from the Type drop-down list. Then click on the applicable validation rule you would like to change, and make the necessary changes.

Deleting a validation rule

There are two options available when deleting a validation rule:

1. The rule can be physically deleted. This can be done by clicking on the Delete Business Ruleicon from the Business Rule >> Edit page.

Delete_Business_Rule_icon.jpg

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.

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.

Make_Business_Rule_inactive.jpg

For more information on the web services, access the following knowledge base article and for more information on the e-mail notifications, read the following knowledge base article.

Was this article helpful?
1 out of 1 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