Beyond the standard handling of fields not being validated by our APIs there are some additional error scenarios to be aware of.
If an EDQ Profile Setting hasn't been created for the profile used by passive validation then the validation won't be executed. If the field doesn't already have an EDQ Log object associated with it holding its validation status then a new EDQ Log will be created indicating why the validation wasn't performed. Providing you have one of our EDQ components enabled the field will be accompanied by a validation status indicating that it was not validated due to the profile either not being configured at all or not enabled for the validation type in question, for example:
In the case of Duplicate Matching Rules being set to Allow with Alert or Block our passive validation will prevent the address/email/phone field from being updated. This mirrors the default behavior of Salesforce for Web-to-Lead submissions with Duplicate Matching Rules configured in this way. In this scenario an error will be logged to the EDQ Error Logs, for example:
An EDQ Log will only be created if one doesn't already exist for the field in question, as we don't want to overwrite the existing log containing the status for the original field value. If no EDQ Log already exists and the field validated correctly (i.e. with a 200 HTTP response from the API) an EDQ Log will be created with a MANUALLY UPDATED validation status.
In the case of Duplicate Matching Rules being to set to Allow passive validation will execute normally and display the status accordingly.
In the case of an API error (non-200 HTTP response) or network failure during the call to the API methods, an error will be logged to the EDQ Error Logs and the the field will be accompanied by a validation status of Not validated along with the timestamp:
