Full Family Tree Product

IMPORTANT: Authorization is required from your D&B representative before registering for this product.
Family Tree Monitoring is a joint venture between the D&B Direct+ and D&B Direct+ Monitoring teams to deliver notifications which are complementary to the existing Family Tree API.

The following are specific to Family Tree Monitoring Registrations:

The only notification type that is permitted is SUMMARY. This is a new notification artefact which differs in format to any of our existing notifications. SUMMARY can only be used on Family Tree Registrations.
SEED on demand is not currently available. A seed file will be provided in the following scenarios:
- A new registration is created.
- An edit registration is initiated.
- A new GU is created when a DUNS of Interest moves to a tree that is not already being monitored on.
D+ Monitoring Family Tree is INTRA_DAY only as the SUMMARY notification acts as linear picture of changes - i.e. aggregation using other frequencies would not provide insight or value.
Direct+ will provide the full Family Tree artefact and perform error and exception handling. D+ Monitoring's primary responsibility is user registration management and routing of artefacts.
Family Tree Registrations will be set to Unsuppressed by default, upon creation. This is to ensure the sequential flow of the artefacts is maintained (i.e. the SUMMARY notifications will build out from the initial SEED)
Delivery Trigger is PUSH only.
Add Single Subject/Add Single D-U-N-S is not supported.

Registration

Please refer Create a Registration page for details. The Family Tree Monitoring registration has replicated how the existing monitoring registrations look for the end-user - with some slight deviations outlined below.

Parameters specific to Family Tree

Users should be aware of the following unique attributes for a Family Tree Monitoring Registration:

productID is FULL_FAMILY_TREE
seedData is true
notificationType is SUMMARY
deliveryTrigger is PUSH only

Appendix

DUNSMap (Mapping file)

The following artifacts are delivered to the users:

Given that upon successful creation of a create or edit Registration, when the DUNSMap file is created, then it will contain the latest mapping of all of the duns to their corresponding global ultimate duns:
```
{"duns":"804735132","gu":"804735132"}
```
If a DUNS of Interest submitted is a standalone DUNS (i.e. no GU) then the following response will be returned:
```
{"duns":"804735132","gu":"standalone"}
```

Seed

Given that some existing monitoring users are used to the Family Tree API, we have replicated the fabrication of this file to match this. It contains latest family trees available:

Summary

For each GU we show the changes that have occurred since the last cutoff. They are grouped by change type and include the list of 'DUNS of Interest' first:

{"duns":["804735132"],"gu":"804735132","added":[],"detached":[],"moved":["754683795"]}

States	High-Level Definition
Added	DUNS added to tree.
Detached	DUNS moved to become a standalone DUNS. Has no parents or children.
Moved	DUNS moved from one GU to another, it now has a new GU. Or DUNS has moved from under one parent to under another (whilst remaining under the same GU).

If there is no DUNS in the array then the array name will appear with brackets [] e.g. "detached":[] . This maintains the structure of the summary information for each GU.

Exisiting Monitoring API Calls

The existing API calls listed will work for Family tree Monitoring also:

Get Details
Get Status
Add/Remove list of D-U-N-S
List Pending Deliveries
DUNS check
DUNS export
Push notifications
Suppress
Unsuppress
Delete registration
GU Count (Note: this will not be updated during the "edit" DUNS action so may be out of sync until the next publication/distribution run. As INTRA_DAY is the frequency cadence then we think this has a minor impact. It will be updated during "create" and every run.)
Single Add/Remove D-U-N-S is not supported for Family Tree registrations

Change Scenarios

Starter Trees

Starter tree

Change Scenario	Sample Tree	Notification File Format
A gets new parent; becomes new child under J. J is an existing entity.		Format: {"Duns of Interest":[Uploaded DUNS of Interest for this tree will be here],"gu": "A", "added":[], "detached":[], "moved":["A", "B", "C", "D", "E", "F"]} {"Duns of Interest":[],"gu": "J", "added":["A", "B", "C", "D", "E", "F"], "detached":[], "moved":[]} Logic: Original Tree A-F has been moved under a new parent of J ("moved"). Tree A-F is "added" to the existing entity J. In this scenario D+ Monitoring will have logic to send out a seed file, because we are guaranteed that one of the DUNS from A to F must be DUNS of interest so will then be registered under a new GU of J - this will trigger a seed.
A gets new child		Format: {"Duns of Interest":[Uploaded DUNS of Interest for this tree will be here],"gu": "A", "added":["M"], "detached":[], "moved":[]} Logic: M is added to this tree.
D gets new child		Format: {"Duns of Interest":[Uploaded DUNS of Interest for this tree will be here],"gu": "A", "added":["G"], "detached":[], "moved":[]} Logic: G is added to this tree.
C moves under B		Format: {"Duns of Interest":[Uploaded DUNS of Interest for this tree will be here],"gu": "A", "added":[], "detached":[], "moved":["C"]} Logic: This move of a child from one parent to another (under the same GU) is recorded as a "moved". In this scenario there is a "moved" notification, but no "added" notification. This is because the GU has not changed for this DUNS in question. Therefore, the end user can derive that this DUNS in question has moved to a different parent under the same GU.
D leaves tree; changes to standalone		Format: {"Duns of Interest":[Uploaded DUNS of Interest for this tree will be here],"gu": "A", "added":[], "detached":["D"], "moved":[]} Logic: D becomes a standalone DUNS (orphan with no parents or children). As it does not join another tree, there are no other notifications.
A moves to another existing tree		Format: {"Duns of Interest":[Uploaded DUNS of Interest for this tree will be here],"gu": "A", "added":[], "detached":[], "moved":["A", "B", "C", "D", "E", "F"]} {"Duns of Interest":[Uploaded DUNS of Interest for this tree will be here],"gu": "Z", "added":["A", "B", "C", "D", "E", "F"], "detached":[], "moved":[]} Logic: All DUNS including the GU itself are moved from A and added to Z.
C moves to its own tree		Format: {"Duns of Interest":[Uploaded DUNS of Interest for this tree will be here],"gu": "A", "added":[], "detached":[], "moved":["C", "E", "F"]} {"Duns of Interest":[Uploaded DUNS of Interest for this tree will be here],"gu": "C", "added":["E", "F"], "detached":[], "moved":[]} Logic: C, E and F have left Tree A ("moved"). C is now a new GU with E and F as children DUNS ("added"). In this scenario D+ Monitoring will have logic to send out a seed file, if any of C, E or F are DUNS of interest.
C, E and F move from Tree A to under a child in Tree Z		Format: {"Duns of Interest":[Uploaded DUNS of Interest for this tree will be here],"gu": "A", "added":[], "detached":[], "moved":["C", "E", "F"]} {"Duns of Interest":[Uploaded DUNS of Interest for this tree will be here],"gu": "Z", "added":["C", "E", "F"], "detached":[], "moved":[]} Logic: All DUNS including the GU itself are moved from A and added to Z.
The DUNS B is deleted in D&B		Out of scope: Deemed out of scope due to the following reasons: A that a delete scenario is the same as any other delink scenario where a DUNS is removed from a tree. The fact that it came from a delete isn't relevant for informing of the delink having happened. The delete in this case would be the reason that the company became delinked from the tree and the reason is not something that we vend today and if we were going to communicate that a delete caused a delink I would expect it would be only when we are in a position to communicate the reason for all delink scenarios (merger, divestment, Out of Business etc etc) and Delete would be one of many possible values in the reason text.
A gets new parent; becomes new child under J. J is a new entity.		Format: {"Duns of Interest":[Uploaded DUNS of Interest for this tree will be here],"gu": "A", "added":[], "detached":[], "moved":["A", "B", "C", "D", "E", "F"]} {"Duns of Interest":[Uploaded DUNS of Interest for this tree will be here],"gu": "J", "added":["A", "B", "C", "D", "E", "F"], "detached":[], "moved":[]} Logic: Original Tree A-F has been moved under a new parent of J ("moved"). Tree A-F is "added" to entity J. If new GU is created and the GU or children are D+ Monitoring DUNS of interest then we will send a seed.