When working with the model-driven applications, we can make a field required, but, normally, that would not make any difference for server-side processing. That field will be required on the form:
But I would have no problem at all using “empty” value for that field through the API/SSIS/etc. Or, as in the case below, by importing those changes back to CDS through Excel Online:
Here is the end result – the field is empty now:
So, what if the field were not required through the configuration, but there were a business rule that would make it required?
As you can see below, I’ve updated field configuration to make that field optional:
Now let’s add an entity-scoped business rule:
That rule would make the field required when there is some value in the “Name” attribute.
Would it be required all the time now? This is where things are getting interesting.
It is definitely required on the form now, so I just put some text value into the field:
I can open Excel Online and make a change, though. Instead of “Updated value” which is there at this point:
I’ll put empty value in the field:
It’s not a problem, it seems. Actually, it’s what I would expect since it’s what I always used to think – “required” fields are only validated on the client:
Now what if I open Excel Online again and modify the “Name” of that record?
There will be an import error this time:
And the error would tell me that my test attribute is, actually, required:
Even though I have not even touched it this time around.
To summarize. This kind of business rule will kick in because it will be triggered by an update of the field used in the business rule condition. From there, “Entity”-scoped rule will enforce required level on the server side, no matter if the fields affected by the rule are modified or not as part of the operation. In other words, somewhat unexpectedly this kind of rule will enforce server-side validation… but only if it gets triggered.