This article describes a recent change in how Business Rules are executed when Requester Groups or Requested For Groups are configured as conditions in Service Items. Previously, the validation logic did not function accurately. This issue has now been fixed, ensuring proper validation execution.
Existing issue
The business rule validation was not functioning accurately when configured for Requester Groups or Requested For Groups in Service Items. Requesters belonging to these groups observing that validation does not run in specific scenarios:
When an agent raises a service item on behalf of a requester.
Form validation upon submission.
Expected changes in behavior after fix implementation
- Validation Execution: Previously, the validation was incorrect, but after the fix, it will execute as expected.
- Deviation in Behavior with Auto Reverse if False - For example, let's assume a form has 4 mandatory fields. A business rule mandates 2 out of 4 fields if the logged-in user's department is HR. The reverse means if the user is from any other department, those fields are non-mandatory. If this behavior is expected, then the Auto Reverse if False checkbox must be set accordingly.
You will notice that validation now functions differently, and in some cases, deviations may occur based on previous incorrect behavior.
Actions Required
Before the fix is rolled out (until March)
Do not configure business rules for Service Items > Requester Groups or Requested For Groups.
After the fix is rolled out (April onward)
Review and Adjust Business Rules: If you have configured business rules using Requester Groups or Requested For Groups, ensure they still work as expected.
Test Business Rules:
Run tests to verify that business rules execute correctly.
Check if the "Auto Reverse if False" option needs to be enabled or disabled based on the expected scenario.
Scenario examples
Scenario 1: Request Validation Issue
Before the fix (previous behavior)
A business rule prevents agents from raising a service item if the Requester or Requested For user belongs to Test Requestor Group.
If David Finch (who belongs to Test Requestor Group) is the requestor, the service request should be successful.
However, due to the bug, validation incorrectly blocks the request.
After the fix (new behavior)
The validation now works as intended, allowing service requests when the correct conditions are met.
Scenario 2: Field Validation Issue
Before the Fix (previous behavior)
A business rule removes the "8 GB" memory option for an Office Desktop if the Requester or Requested For belongs to Test Requestor Group.
When David Finch is the requestor, the 8 GB memory option should be hidden, but it remains visible due to validation failure.
After the Fix (new behavior)
The validation now correctly removes the "8 GB" memory option for users in the Test Requestor Group.
Important considerations
Handling null values in conditions
If both "Requester Groups" and "Requested For Groups" are used in conditions, values must be provided in the form fields.
If these values are left empty, the system cannot validate conditions correctly, causing business rules to fail.
Configuration changes required
If your business rules use Requester Groups or Requested For Groups, review and update your configurations:
Verify Business Rule Execution: Ensure it aligns with expected behavior post-fix.
Test Business Rules: Conduct tests with different user groups.
Enable/Disable "Auto Reverse if False" Based on Expected Outcome.
