When attempting to load an specific entity type record for an existing profile, the system throws a DVF error, causing the load to fail.

Gloria

March 13, 2026 21:23

Problem

When attempting to load a record for an existing profile, the system throws a DVF error, causing the load to fail.

Attribute First Name must have at most 1 ov value(s), but it has 2 
Attribute Last Name must have at most 1 ov value(s), but it has 2 
Attribute Gender must have at most 1 ov value(s), but it has 2

This occurs even though:

The profile already has valid values for:

CountryCode
Salutation
FirstName
LastName

No changes are being made to these attributes as part of the load.

Answer

What is happening

The payload is a partial entity update: it sends AZCustomerID, AlternateContact, and a crosswalk, but not CountryCode, FirstName, LastName, or Prefix/Salutation. When a partial override is used, only the attributes provided in the request are overwritten, so an alternateContact-only request does not resend the identity block.

The validation engine evaluates the provided payload/object against active DVF rules and returns errors/warnings based on that evaluated object. The API in this case is payload-centric, not “persisted golden record”-centric.

Why can this fail even when the profile already looks complete

The OV flag is calculated just-in-time whenever entity values are requested. That means the effective “resolved” view of the entity can change as other sources update, survivorship outcomes change, or crosswalk contributions change.

So even if the profile snapshot shows CountryCode=Italy, FirstName=MATILDE, LastName=PONTILLO, and Prefix=Ms, a retry can behave differently if other jobs touched the entity between attempts and changed the runtime-resolved state that validation or save processing sees. This is consistent with a“fails once, succeeds later” pattern.

Why did the retry succeed later?

Using activity analysis is a valid troubleshooting method because Reltio’s Activity Log tracks modifying REST API requests and stores details about changed objects, including attribute changes. That lets you verify whether different CGD/Aspen/Mule sources update identity attributes between failed and successful attempts.

Given the official OV behavior, it is reasonable to conclude that the intervening updates changed the effective resolved entity state, thereby allowing the same alternateContact payload to pass on replay. That conclusion is an inference, not based on customer-facing documentation in a direct quote from public docs.

Cardinality issue, you should call out separately

The Cardinality Validator checks OV values against the configured min/max cardinality, indicating that the cardinality applies only to OV values. So if you have multiple OV values where maxValue=1, that can create separate validation noise or nondeterministic-looking behavior depending on survivorship.

What to check next

Use this checklist with the customer:

Confirm whether the failing request used partialOverride or another partial-update pattern for nested AlternateContact. Public docs confirm that partial updates only overwrite attributes present in the request.
Review the DVF definitions on CountryCode, Salutation/Prefix, FirstName, and LastName to see whether they are written as simple null/blank checks on the evaluated object. Reltio documents that DVFs are defined on attributes with expressions, actions, and messages.
Pull _activities / Activity Log around the exact failure and retry timestamps to identify which source jobs reasserted the identity block between attempts.
Inspect survivorship/OV behavior for those required attributes, because OV is calculated just-in-time and can differ after source updates.
Check for cardinality violations on attributes with maxValue=1 because those validators operate on OV counts and may be affected by survivorship bias.

Documentation

These are the strongest public references:

Validate entities using DVF
DVF is evaluating the submitted object/payload: Reltio says the API “validates the request payload against active DVF rules” and “validates data only and does not persist entity records.”

Validate data before ingestion
Reltio says pre-ingestion validation “uses the same DVF rules” and “evaluates the provided payload against active DVF rules.” The DVF logic is payload or object-based.

Partial overrides
Reltio says “only attributes that are provided in a request will be overwritten,” which supports an alternateContact-only update does not inherently bring along the full identity block.

Survivorship rules
Reltio says OV is “calculated just-in-time whenever the entity’s values are requested.” This supports why retries can behave differently after other updates.

Search using Activity Log API
Reltio documents that change-producing API requests are tracked by attribute changes, which supports using activity history to explain what changed between failure and success.

Configure validation service / Cardinality
This documentation supports that multiple OV values with max=1 are real validation concerns and may depend on survivorship outcomes.