ABContact domain graph and related entities
There are several ways that an entity can be considered part of the ABContact domain graph. There are also entities that require special handling or are explicitly excluded from the graph.
- The entity is included in the purge graph because it implements Extractable.
- The entity is included in the purge graph because it has a foreign key to ABContact.
- The entity might qualify for purging, but requires special handling.
- The entity is a shared resource and is therefore excluded from the purge graph.
Entities that implement Extractable
The following entities are defined as part of the domain graph and are automatically purged along with ABContact:
- PendingContactChange
- PendingContactCreate
- PendingContactUpdate
- ABContactCategoryScore
- ContactHistory
- TrackedChange
- ABContactTag
- ABContactSpecialistService
- ABContactDocumentLink
- EFTData
- ReviewSummary
- ReviewSummaryCategoryScore
- Address
Addresses are connected to the domain graph in two ways, directly defined in ABContact as a PrimaryAddress or as part of ABContactAddress. Addresses are not a shared resource among ABContact objects and are exclusive to the ABContact they are associated with, so they can be safely purged along with the ABContact.
- ABContactAddress
- ABContactContact
Acting as a specialized edge foreign key, this object references ABContact through the SrcABContactID and the RelABContactID fields. In the base configuration, these fields are cross domain links, which can be safely severed from the other contacts.
- MergeContactPair
Merge contact pairs are automatically purged along with ABContact, which will automatically severs relationships between that contact and any contacts that are duplicates. There is special handling for a contact that is marked as a retired MergeContactPair object.
MergeContactPair objects represent a sort of versioning system for contacts. In the system there can be a number of contacts that, while different objects, really represent the same thing. The system has the ability to denote one version of the contact as the kept version, the official representation of the contact. The other versions are demoted and retired, but the system is able to keep track of them. These obsolete versions are called retired versions, and you can think of them as replaced by the kept version. MergeContactPair entities are used by ContactManager to help represent this kept and retired versioning.
There are special conditions that apply to the ABContact object itself when a MergeContactPair exists:
- If the contact being purged is the kept contact, then the purge destroys not just it, but also any retired versions of that contact.
- If the contact being purged is a retired contact, attempting to purge that contact causes an exception to be thrown. The exception informs the user that deleting the contact is prohibited, and that deleting the contact requires explicitly purging the kept version of that contact.
Entities with foreign keys to an ABContact object
The following entities have foreign keys that point to an ABContact object, but there is no foreign key from the ABContact object to the entity. These entities do not implement Extractable and are purged explicitly by ContactManager along with ABContact.
- ABContactScoringWorkItem
Deleted during the purge by ContactManager.
- DuplicateContactWorkItem
Any that reference the contact are purged by ContactManager. Even though the entity references ABContact by using a non-nullable foreign key, deleting the entity is not flagged as problematic by the graph validator.
- MessageHistory
Deleted during the purge by ContactManager.
- Message
Deleted during the purge by ContactManager.
Entity requiring special purge handling
The DuplicateContactPair entity requires special handling. The ABContact entity cannot be purged if the contact continues to be referenced by any DuplicateContactPair.
ABContact is referenced by two non-nullable foreign keys, ContactID and DuplicateContactID. These two foreign keys are marked as cross domain, which makes DuplicateContactPair severable.
Purging will fail and throw an exception if an ABContact is referenced by any DuplicateContactPair entity, either as the contact or as the duplicate contact. A user of ContactManager must use the Merge Duplicates screens to resolve duplicates first. Only when there are no references will purging be allowed.