Merging Contacts

See Also

Permissions Required

Edit Contacts - To Edit Contacts.

This feature enables you to merge two Contacts so that Talisma recognizes that two different e-mail addresses refer to the same Contact.

Example   When a Contact sends a message from an e-mail address, self@ABC.com, Talisma creates an Interaction, and a Contact using the address information from this e-mail message. Now, if the same Contact sends a follow-up message from another e-mail address, self@myhome.com, Talisma will not be able to detect that the Contact already exists, and creates an Interaction and a Contact. You can merge the two Contacts, enabling Talisma to associate the two e-mail addresses with a single Contact. Consider two Contacts - A and B. If you choose to merge Contact A with B, all Property values of Contact B are retained, including the name of the Contact. However, you can choose to retain some Property values of Contacts A and B by selecting the Properties individually.

 

Note  •   You can merge two Contacts only if the value of the Integration flag Property of the first Contact is Not integrated. This condition is applicable only in a scenario where Talisma Higher Education Foundation is installed and the Talisma system is integrated with an external Student Information System (SIS) using an SIS Connector component. •   When two Contacts are merged, you can choose to retain Properties from both the Contacts. By default, read-only Properties of the second Contact are retained. However, you can choose to retain the Read-only Property values of the first Contact. Also, the ID of the second Contact is retained for the merged Contact. All other details of the two Contacts displayed in the tabs of the Contact window are retained in the merged Contact. •   You cannot edit the Retained Value of a merged read-only Property. For example when you merge the Property values of the Created Read-only Property associated with two Contacts A, and B. you can choose to retain the value of the Created Read-only Property associated with Contact A. The Retained Value of this Property cannot be edited.

To Merge Contact Items

1.  Using the Left pane, locate and select the two Contacts you want to merge.

2.  From the Contact menu, select Merge.

The Merge Objects dialog box is displayed. The Properties of the Contact Object are displayed in the Field column. The values of the Contacts are displayed in the relevant columns.

The Merge Objects Dialog Box

3.  To retain a Property value of the first Contact, select the appropriate value in the second column. Similarly, to retain a Property value of the second Contact, select the appropriate value in the third column.

- OR -

To retain all Property values of the first Contact, click Select 1.

- OR -

To retain all Property values of the second Contact, click Select 2.

The selected Property values are displayed in the Retained Value column.

4.  Click Clear to clear all the selected Properties.

- OR -

Click OK to merge the Contacts.

The two Contacts are merged.

Note  •    In the same row of the Preferences tab, values in the source contact are overwritten by values in the same field of the destination contact. Additional rows in the source contact that are not in the destination contact are added to the destination contact. Common values are retained in the destination contact. •   In a scenario where the Contacts you want to merge have a One to Many, or a Many to Many Relationship with another Object, details of Object items related to both Contacts will be displayed in the Object List type of tab of the merged Contact. •   You can merge two Contacts by selecting both Contacts in the Table View and clicking Merge from the shortcut menu. •   You can merge two Contact items from the Contact window, by selecting Merge from the Contact menu. In such a case, you must specify the ID of the second Contact in the into field in the Merge Objects dialog box. •   If you have selected only one Contact from the Contact Table View, and opened the Merge Objects dialog box, you must specify the ID of the second Contact in the into field. •   You can manually change the values for Properties from the Retained Value column. •   You cannot merge Contacts if e-mail messages from one or both the Contacts, have been blocked. •   You cannot merge Contacts if one of the Contacts has been deleted. •   In a scenario where the Contact Object has a One to Many or a Many to Many Relationship with the Lead, Address, or Custom Objects, items of the related Objects are displayed in the related Object tabs of the Contact window. In the Contact window, you can merge two related Object items by selecting the items from the related Object tab and selecting Merge from the shortcut menu. To merge the related Object items, you must have the Permissions to perform the operation. For more information about Permissions, see Permissions. •   When two Contacts, Contact 1 and Contact 2, that are Targets of an active Campaign are merged, the Campaign will retain both Contact 1 and Contact 2 as Targets. Further, if a Mailer is configured for the Campaign, two Mailers will be sent to the merged Contact instead of one.

Usage Scenarios of Merging Contacts

When Team-based security is enabled for the Contact Object, you can merge two Contacts if:

•   Contacts that you want to merge are shared with the same Teams. For example:

◦   Jane and Mary are two Contacts in Talisma.

◦   Jane and Mary are shared with Team A and Team B.

Samantha is a Talisma Client User who has access to Team A and Team B. Samantha will be able to merge Jane and Mary successfully and the merged Contact will be shared with Team A and Team B.

•   The source Contact that you want to merge is shared with a subset of Teams the destination Contact is shared with. For example:

◦   Jane and Mary are two Contacts in Talisma.

◦   Jane is shared with Team A and Team B.

◦   Mary is shared with Team A, Team B, and Team C.

◦   Samantha is a Talisma Client User who has access to Team B. Samantha will be able to merge Jane into Mary. However, Samantha will not be able to merge Mary into Jane because Mary is shared with Team C.

For more information about Team-based security for the Contact Object, contact Talisma Product Support.

Usage Scenarios of Sending Information to the Outgoing Queue

Scenario 1

•   The Contact and Address Objects share a One to Many Relationship where Contact is on the One side of the Relationship.

•   The following Rules are configured in Talisma Business Administrator for the Contact Object:

Rule 1

On event: When Object is updated

IF: Contact.Integration flag = Integrated

Then:

Send <Update> Information to Outgoing Queue

Rule 2

On event: When Object is updated

IF: Contact.Integration flag = Integrated AND Address.Integration flag = Not Integrated

Then:

Send <Create> Information to Outgoing Queue

Set Integration flag Property to Integrated

IF: Contact.Integration flag = Integrated AND Address.Integration flag = Integrated

Then:

Send <Update> Information to Outgoing Queue

•   The value of the Integration flag for the following Objects items are as follows:

◦   Contact A = Not Integrated

◦   Contact B = Integrated

◦   Address 1 = Not Integrated

•   Contact A is associated with Address 1.

•   Some Properties of Contact A are retained in Contact B.

In this scenario, the following operations occur in Talisma when Contact A is merged into Contact B:

•   Address 1 of Contact A is added to Contact B.

•   Rule 1 and Rule 2 are triggered. As a result:

◦   An Outgoing Queue item of type Update is created for Contact B.

◦   An Outgoing Queue item of type Create is created for Address 1.

◦   An Outgoing Queue item of type Update is created for Address 1.

Scenario 2

•   The Contact and Account Objects share a Many to Many Relationship where Contact is on the Many side of the Relationship.

•   A Rule, Rule 1, is configured in Talisma Business Administrator for the Contact Object:

On event: When the value of a Property on <Contact - Previous EducationMANY -

MANYAccount - Student> is changed

IF: Contact.Integration Flag = Integrated And Contact.ContactType = Student

Then:

Send <Associate> Information to Outgoing Queue

In this scenario, the following operations occur in Talisma when Contact A is merged into Contact B:

•   Previous Education details of Contact A is added to Contact B.

•   Rule 1 is triggered. As a result, for Contact B, an Associate XML is sent to the Outgoing Queue.

Scenario 3

•   The Contact and Account Objects share a Many to Many Relationship where Contact is on the Many side of the Relationship.

•   A Rule, Rule 1, is configured in Talisma Business Administrator for the Contact Object:

On event: When the value of a Property on <Contact - Agency/3rd Party MANY -

MANY Account - Student Agency/3rd Party> is changed

IF: Contact.Integration Flag = Integrated And Contact.ContactType = Student

Then:

Send <Associate> Information to Outgoing Queue

In this scenario, the following operations occur in Talisma when Contact A is merged into Contact B:

•   Agency/3rd Party details of Contact A is added to Contact B.

•   Rule 1 is triggered. As a result, for Contact B, an Associate XML is sent to the Outgoing Queue.

Scenario 4

•   The Contact and Ethnic Group Objects share a Many to Many Relationship where Contact is on the Many side of the Relationship.

•   A Rule, Rule 1, is configured in Talisma Business Administrator for the Contact Object:

On event: When a row is added to <Ethnic Groups>

IF: Contact.Integration flag = Integrated And Contact.Contact type = Student

Then:

Send <Associate> Information to Outgoing Queue

In this scenario, the following operations occur in Talisma when Contact A is merged into Contact B:

•   Ethnic Group details of Contact A are added to Contact B.

•   Rule 1 is triggered. As a result, for Contact B, an Associate XML is sent to the Outgoing Queue.

Scenario 5

•   The Contact and Pronoun Objects share a Many to Many Relationship where Contact is on the Many side of the Relationship.

•   A Rule, Rule 1, is configured in Talisma Business Administrator for the Contact Object:

On event: When a row is added to <Pronouns>

IF: Contact.Integration flag = Integrated And Contact.Contact type = Student

Then:

Send <Associate> Information to Outgoing Queue

In this scenario, the following operations occur in Talisma when Contact A is merged into Contact B:

•   Pronoun details of Contact A are added to Contact B.

•   Rule 1 is triggered. As a result, for Contact B, an Associate XML is sent to the Outgoing Queue.

Note  •   When the Contact, Account, Address, and Lead Object items are merged, Outgoing Queue items of type Update are created if a Rule with the When Object is updated Event is configured for these Objects in Talisma Business Administrator. •   Irrespective of the value of the Integration flag of Account Object items, any updates to the Account Object items in Talisma always creates an Outgoing Queue items of type Update. •   Irrespective of the value of the Integration flag of Ethnic Group Object items, any updates to the Ethnic Group Object items in Talisma always creates an Outgoing Queue items of type Associate.