Whenever Nektar gets new data from any connector, it re-evaluates all its past data capture decisions in light of the new information, correcting any errors with the benefit of hindsight. Here are just a few example scenarios:

• The first contact is added to a Salesforce account. Nektar might find old conversations with that contact and add it to Salesforce. Nektar might also find old conversations with others in the same company, and add those contacts and their activities to the account.
• A lead is added to Salesforce. If Nektar had previously created a contact for this person, its details and activities are merged into the lead and the Nektar-created contact deleted.
• A contact is added to a Salesforce opportunity. Nektar might reassign the past activities with this contact to this opportunity, and might also add the participants in those activities as opportunity contacts.
• A preexisting contact is added to an ongoing conversation. Nektar might reassign related emails and events to an opportunity this contact is in.

This is not an exhaustive list. These scenarios are not special cases that Nektar is programmed to do, but are simply emergent behaviors of Nektar data processing architecture.

Important notes

1. For self-healing to work correctly, Nektar might need to undo any of its data capture decisions, including record creation. This is why Nektar requires permission to delete records it created.

2. One may edit a Salesforce record to correct something (where the previous value was always wrong, e.g. contact phone number), or to update something that changed (where the previous value was correct on an earlier date, e.g. opportunity stage).

   Nektar assumes that all changes are corrections, never updates. While Nektar’s built-in features work correctly under this assumption, it’s something to keep in mind when building custom transform rules.