How D&B RIH Recipes Update Address Data in Reltio DnB DataBlocks

Gloria

Updated July 23, 2026 21:53

Overview

When D&B Datablocks enrichment runs — whether via real-time event, UI button, or batch schedule — the RIH recipes follow a specific sequence to match a Reltio Organization profile to a D&B DUNS record and write verified address data back to the profile. Address data is contained in the Company Info Level 3 V1 data block and is mapped to Reltio's PrimaryAddress reference attribute via the SDK mapping recipe.

Address enrichment depends on correct Velocity Pack configuration Address attribute in Reltio must be configured as a reference attribute with correct surrogate keys per the Velocity Pack spec. If surrogate keys are misconfigured, address enrichment will fail silently or create duplicate address entries on the profile.

Step-by-step flow

Enrichment trigger fires

Any enrichment mode initiates the flow: an ENTITY_CREATED or ENTITY_CHANGED SQS event, a UI button click (Get Match, Get Latest Company Info), or a batch scheduler invocation. The real-time and batch flows converge on the same D&B API call and SDK mapping logic.

Reltio sends address input to D&B for identity resolution

The RIH recipe reads the Organization profile's existing address fields and includes them in the D&B Direct+ identity resolution request as matching inputs: street address, city, state/province, postal code, and country. These are used by D&B to find the best match—they are the inputs to the match, not necessarily what gets written back.

D&B performs identity resolution and returns a Confidence Code

D&B's Direct+ API attempts to match the entity using the supplied firmographic data, including address. It returns a Confidence Code (0–10)indicating match quality and, if a match is found, a DUNS number. The Confidence Code determines whether the match auto-merges or creates a Potential Match in Reltio.

D&B returns the Company Info L3 data block containing verified address data

On a successful match, D&B returns the requested data blocks. The Company Info Level 3 V1block contains D&B's verified address data for that DUNS, which may include primaryAddress, registeredAddress, and mailingAddress depending on D&B's records.

SDK mapping recipe maps D&B address fields to Reltio attributes

The mapping recipe translates D&B's address sub-fields into Reltio's attribute structure. In real-time mode, this happens inside D&B | PROC | Real Time Enrichment – Match and Append. In batch mode, this is handled by D&B | SYS | Batch Update Company Information – Reltio Load. Both use the same SDK mapping logic.

Enriched address is written to the Reltio Organization profile via API

The mapped address data is written back to Reltio as a D&B source crosswalk on the Organization entity. The D&B-sourced address contribution is added to the profile and participates in survivorship along with other source contributions (CRM, ERP, manual entry, etc.).

Address fields sent to D&B

The following Reltio Organization attributes are read by the recipe and included in the D&B identity resolution request as matching inputs:

D&B input parameter	Reltio source attribute
`streetAddressLine1`	Primary address line 1
`addressLocality.name`	City
`addressRegion.abbreviatedName`	State / Province
`postalCode`	Postal / ZIP code
`addressCountry.isoAlpha2Code`	Country (ISO 2-letter code)

Better input = better match. D&B's identity resolution accuracy improves significantly when full, structured address data is present on the Reltio profile prior to enrichment. Profiles missing postal code or country are more likely to receive a low Confidence Code or no match.

Address fields returned by D&B

D&B returns address data within the Company Info Level 3 V1 data block. The following address types may be present depending on the DUNS record:

D&B address type	Description	Maps to Reltio
`primaryAddress`	The main operating address D&B has on file for the entity	`PrimaryAddress` reference attribute
`registeredAddress`	Legal / registered address (may differ from operating address)	Mapped if block config includes it
`mailingAddress`	Postal / mailing address	Mapped if block config includes it

Each address object from D&B contains the following sub-fields:

D&B sub-field	Example value
`streetAddress.line1`	100 Summer Street
`addressLocality.name`	Boston
`addressRegion.abbreviatedName`	MA
`postalCode`	02110
`addressCountry.isoAlpha2Code`	US
`isRegisteredAddress`	true/false
`isPrimaryAddress`	true/false

SDK mapping recipe — how fields are written to Reltio

The SDK mapping recipe is where D&B's address sub-fields are translated into Reltio's attribute structure. The key recipes responsible are:

Real-time: D&B | PROC | Real Time Enrichment – Match and Append (address mapping is performed as part of the inline enrichment steps)
Batch: D&B | SYS | Batch Update Company Information – Reltio Load (dedicated load recipe, step 8 of the batch chain)

The mapping follows this pattern:

D&B field	Reltio attribute path	Notes
`primaryAddress.streetAddress.line1`	`PrimaryAddress / StreetAddress1`	Main address line
`primaryAddress.addressLocality.name`	`PrimaryAddress / City`
`primaryAddress.addressRegion.abbreviatedName`	`PrimaryAddress / State`	2-letter state/province code
`primaryAddress.postalCode`	`PrimaryAddress / PostalCode`
`primaryAddress.addressCountry.isoAlpha2Code`	`PrimaryAddress / Country`	ISO 2-letter code

Address attribute must be a reference attribute. In the Reltio L3 config, PrimaryAddress must be defined as a reference attribute with surrogate keys configured per the Velocity Pack spec. The SDK mapping recipe uses the surrogate key to uniquely identify and upsert the address contribution from the D&B source. Without surrogate keys, each enrichment run may create a new address entry rather than updating the existing one.

The enriched address is written to Reltio tagged with the D&B source system crosswalk (e.g. DNB or the configured source system label). This means the D&B address contribution participates in survivorship alongside contributions from other sources such as Salesforce, SAP, or manual entry. If D&B has higher survivorship priority, its address will win on the golden record.

Troubleshooting address enrichment issues

Address not updating after enrichment runs

Confirm the enrichment recipe completed successfully — check the RIH job log for errors at the SDK mapping step.
Verify that the Company Info Level 3 V1 block is enabled in the D&B Recipe Properties Lookup Table (companyInfo: Yes).
Check that the PrimaryAddress attribute is a reference attribute in the tenant's L3 config with surrogate keys defined.
Check survivorship rules — the D&B address may be writing correctly but losing survivorship to another source with higher priority.

Duplicate address entries appearing on the profile

Almost always caused by missing or incorrect surrogate key configuration on the Address reference attribute. Each enrichment run creates a new reference record instead of updating the existing one.
Fix: correct the surrogate key in the L3 config and re-run enrichment. Existing duplicates may need to be cleaned up via hard delete on the D&B crosswalk records.

Address fields partially populated

D&B may not have complete address data for the matched DUNS. Check the raw D&B response in the recipe job log to see which sub-fields were returned.
If the Confidence Code was low (below the auto-merge threshold), address data from a weak match may be incomplete.

Address not being sent as input to D&B

The recipe reads address from the Reltio profile at trigger time. If the profile has no address data, D&B matching relies on Name, Phone, URL, and Tax ID alone — which may produce a lower Confidence Code.
Ensure the Organization profile is populated with at least City and Country before enrichment is triggered for best results.

How to get the D&B raw response for a specific profile: In RIH, open the relevant recipe job (real-time: the PROC Match and Append job; batch: the TRG Process D&B Job Result job). Expand the step that calls the D&B API and inspect the response payload to see the exact address fields D&B returned for that DUNS. This is the fastest way to confirm whether the issue is with D&B's data or the mapping logic.