This feature was added to make field defaulting more flexible. It uses the data validation logic already in place to set field values based on specified criteria.
There are a couple special options related to field defaults:
Priority - This is a numeric value that accepts decimals. One (1) is the highest priority. Since defaults may overlap, this determines which default takes precedence.
Operator - Explained further below, there are special operators for field default logic.
When specifying fields to default, the following operators are available.
Will overwrite manually entered values.
If Blank, Equals
Will insert a new value if the field is blank.
Used for fields that accept multiple entries, is used to specify which entries to insert.
Must Be Blank
Will force blank values for fields.
The field defaulting logic supports cascading values. In other words, default rules can be chained.
Set a Data Validation Rule as normal. For clarity, this is a way of specifying what criteria will activate the default.
Locate the “Data Validation Chart Defaults” code table.
Specify the desired rule (criteria) that the defaults should fire on.
Set a priority for the default.
Specify the fields that should be defaulted based on the rule.
Step 1 - Create a Data Validation Rule for “Disposition Not Blank”.
This rule will trigger whenever the Disposition field receives a value.
Step 2 - Create a Data Validation Chart Default
With this default, and the “Must Be” operator, the field “Edema” on page 4 will be set to “Not Appreciated” whenever the Dispositions on the chart is not blank.
What happens with Command and Service Level Defaults
Depending on the Operator set, these defaults may get overridden. If the user then elects to re-activate the defaults using the button on the page, then the user’s action will take precedence.
For this reason, services wanting to use the logic based validations may want to consider turning off certain command level defaults.