Basic Customization > User Interface Customization > Presenting Information in the UI > UI Validation > Solutions > Procedure – Pre-Validation > Distinguishing between Pre-Validation Statuses > Action Pre-Validation Statuses
  
Action Pre-Validation Statuses
The validation service and client infrastructure currently support three statuses for pre-validated actions: “enabled”, “disabled”, and “hidden”. As you might suspect, an “enabled” status means that the action is visible to the user and selectable for the user. The “disabled” status means that the action is visible to the user, but not selectable (i.e., the action is “grayed-out”). And the “hidden” status means that the action is not visible at all to the user. Note that there is currently no support to “disable” actions rendered as icons (in a table header or table row, for example). If the validation service returns a “disabled” status for an action icon, the client infrastructure will simply hide the action icon.
Whether you’re implementing a filter or validator to perform pre-validation logic, you’ll be expected to return a validation status (either directly or wrapped in a validation result) to the validation service. (If you implement a solution group, the validation service automatically assigns a “hidden” status to all components deemed invalid by that solution group.)
When trying to choose which status to return from your validator or filter, use the following rules of thumb:
Always err on the side of enabling. If you can’t determine conclusively whether or not an action should be available, give it an enabled status. Chances are there is additional validation that will occur down the line (whether it be another filter, a validator, or post-select validation) when there is more context information available that can disable or deny the user. You’re almost always better off showing a user an action they can’t perform than hiding an action that they should be able to perform.
When trying to choose between hidden and disabled, ask yourself whether the action could ever be visible to the user in the current context. If the answer is yes, then the status should be disabled. For example, the “check-out” action is not valid for an object that is currently checked out. But if that same object wasn’t checked out, the “check-out” action would be available to the user. In that case, a disabled status is appropriate. However, suppose you had an action that was only available to admin users, and your user is a non-admin. In that case, the action would never be available to that user, so a hidden status would be appropriate.