ContactManager provides a web service that enables external software programs to initiate
and track requests to destroy data. In the base configuration, this web service,
PersonalDataDestructionAPI, enables an external application to
request:
- Destruction of a contact’s data by AddressBookUID or by
PublicID.
- Destruction of a user by user name.
In the base configuration, the PersonalDataDestroyer obtained by the
class that implements the PersonalDataDestructionPlugin uses an
ABContact
PublicID. You can configure the PublicID to
correspond to an entity other than ABContact.
The requests for removal return a unique requesterID that can be used
to check the status of the request. Additionally, this requesterID is
available in the plugin notification call when the request has been completed.
Note: The PersonalDataDestructionAPI checks for both retired
and active contacts when a contact data destruction request is received. When
implementing data obfuscation for contacts, you must evaluate the need to look for
related objects that are retired in the database. Retired objects can be obfuscated in
the same fashion as active objects, but must be retrieved from the database with a query
that is specified to look for retired objects. For example:
query.withFindRetired(true).
Important: The external software program that calls the web service must destroy
data for a contact in the core applications before requesting that ContactManager
destroy the contact. If you have more than one core application installed, the external
application must request that the contact be destroyed in all of them before sending the
request to ContactManager. When ContactManager processes a request to destroy a contact,
it first verifies with all installed core applications that it can destroy the contact.
If any core application indicates that the contact cannot be destroyed, ContactManager
does not proceed with the destruction request and notifies the web service that the
contact cannot be destroyed.
See also
