Let’s clarify how business rules work with editable grids once in for all. I keep seeing this discussed passionately and many people believe they don’t work together.
As a note the functionality we’re going to review today works the same for the UCI (Unified Client interface) or the classic editable grid. There currently is a bug with the unified interface version that I need to note here. I feel that this bug may be a cause for a lot of the debate. In writing this blog post it became very clear in the UCI when you switch from the read only grid to the editable grid on the home screen that business rules aren’t being applied. Once I see this issue resolved i’ll post an update to this.
Let’s create a simple business rule that says if the created on date contains data then lock the email field. I’ve tested the scope with all forms or entity and got the same result. In this scenario in order for this business rule to execute it must be able to validate the if condition; this means that the editable view must have the created on field in order to evaluate it. This seems to be something that alludes people frequently.
Checking this business rule against this simple view in the editable grid we see that the email is still editable. As the view doesn’t contain the created on date field.
Let’s create a simpler business rule that checks to see if the email contains data and if it does then lock the email field. I’ve tested the scope with all forms or entity and got the same result. This covers a common scenario that wouldn’t allow the user to change a fields value once entered in the system on the form or editable grid.
Checking this business rule against this simple view in the editable grid we see that the email locked because it contains data. If we clicked on an account record that didn’t have an email value it would be editable until a value was saved in it.
I hope this brings some clarity to how business rules interact with editable grids.
The more you know!