This blog is intended to share insight of a basic challenge related to status progression especially when we have custom validation in place for each status and learning i acquired from one of the recent projects.
Prerequisite:
Background
While setting up any business process, status progression in required sequence is quite important. And it is very basic requirement that only allowed statuses should be visible for a current status for any business transaction and subsequent status should be visible to user only when certain system (custom) validation are successfully performed.
I am sure that you all have thought of ‘Code list restriction’ functionality by now. Partially it is Right as we can easily achieve the status sequence and next allowed status progression by simply creating a code list restriction on status field (code to restrict) with reference to status field (Control Field) as shown below
Limitation: Code list restriction works pretty well when it is only about displaying the next values based on the current values however it has a small limitation when it is used in combination with the custom code validation for e.g. field mandatory checks, party role mandatory validation or any custom validation for that matter etc. Basically with afore mentioned code list ,once we select any status from allowed status then without even saving the transaction it allows you to select the further subsequent status.
Let’s take simple fictitious example to understand it, say we have a custom complaint transaction with below allowed status
And a code list restriction is created in system for status progression as mentioned below
Current Status | Next Subsequent Allowed Status |
New | Information Gathering |
Information Gathering | Ready for Quality |
Ready for Quality |
|
Approved | Closed |
Rejected | Rejected |
Then say we have written a custom code/validation rule on status ‘Ready for Quality’ which checks mandatory fields in product line item and we have a requirement that ‘Approved’ and ‘Rejected’ status should be visible as next available options only when all the mandatory fields are maintained in line item for Ready for Quality status..
However as per current code list config, the moment user select Ready for Quality status, ‘Approved’ and ‘Rejected status’ will become visible and available for selection no matter whether user has saved the transaction. which means all the custom validation maintained for Ready for Quality is bypassed..
Solution Approach
Code list logic
Status Control field (current value) | Allowed Status based on control field status in code list | Set ‘Status Control Field’ once custom validation/s is/are met |
A | New | B |
B | Information gathering | C |
C | Ready for Quality | D |
D |
|
E if approved F if Rejected |
E | Closed | E |
F | Rejected | F |
Summary: Simply by maintaining code list restriction in combination to a custom field and logically using the custom field values in field behavior rules/custom logic, we can achieve the well controlled status sequence in any transaction to met the expected business process.
for e.g. in aforementioned scenario, use combination of status control field ‘C’ and status ‘Ready for quality’ in validation logic for product line item field mandatory behavior and then use workflow/custom logic to change value from C to D only when all the mandatory checks are successfully passed.
Happy Consulting!
Cheers
Govil Banga