When duplicate accounts of a customer can exist. you can merge those accounts into one. One account will be survived and another account will be moved

  • Surviving Account: The customer account that will remain to continue after merging accounts is the Surviving Account.
  • Deactivating Account: The customer account that will be removed after merging is a deactivating account. The account once deactivated cannot be activated again and its data cannot be retrieved. However, the entire data will be validated and moved to the surviving account.

This article covers the following topics.

Approve Account Merge Requests

To approve duplicate accounts merge requests, do the following.

  1. On the left navigation pane, click ID Change Requests > Account Merge. You will see the list of merge requests with details, requested by, account to be merged with, store at which the request is made, and time of the request.
  2.  In the Pending tab, navigate to the desired request and click the respective Approve button.
    • To decline a request, click Decline. In the Decline Coupon Request box, provide the reason for declining this request and click Proceed.
    • The approved and declined requests will move to the Approved and Declined tabs respectively.


Settings for Account Merge Requests

You can configure to notify org POCs on merge requests, automatically approve merge requests without the need of the back-end team to approve it, and notify customers through SMS and email when their accounts are merged.

  1. On the Member Care navigation pane, click Settings > ID Change Request Settings > Account.
  2. In Email these on arrival of request, select the org POCs that you want to notify on new merge requests.
  3. Set Auto approve to On to automatically approve merge requests directly.
  4. In Communicate change to, select whom to notify in case of account merge.
    1. Check Requestor to notify the customer that requested for account merge.
    2. Check Survivor to notify the customer whose remains after merging.
    3. Check both Requestor and Survivor to notify both.
  5. To configure SMS notification, click the Configure button next to Configure SMS and create the message. Use predefined tags wherever required.
  6. To configure email, click the Configure button next to Configure Email. 
    1. In Subject, enter the subject of the email.
    2. In the message body, set up the message body with content and insert images. You can add predefined tags in the message wherever required. To add tags, just click the tag from the list on the left.
    3. Click Save Changes.
  7. Click Save.

Merge Accounts Directly (One Step Change)

To merge duplicate accounts directly, you can use the One Step Change option. Only admin users of an org have access to this feature.

  1. In the Account Merge Change Request page, click One Step Change
  2. In the Existing Box, type the email ID, mobile number, or external ID of the existing account that you want to merge. 
  3. In the Requested To box, type the email ID, mobile number, or external ID of the account into which you want to merge - survivor account.
  4. Click Proceed.

Download Account Merge History

To download accounts merge history as a CSV file, do the following:

  1. On the Account Merge page, click the Download drop-down that appears on the top-right
  2. Set the duration of the requests that you want to download in Start Date and End Date 
  3. In Download, select the statuses that you want to download - Pending, Approved, and Declined.
  4. Click Proceed

The list gets downloaded to your computer as a CSV file.


Effect of account merging on the customer data

After merging, the account that continues to remain is a survivor account and the account that is merged into the survivor account is a victim account.

  • Registration date: The registration date will be the earlier date between the two accounts
  • Transactions: All transactions of the victim will be merged into the survivor's account
  • Points & Coupons: All points and coupons of the victim will be merged into the survivor's account

The following table provides a comprehensive list of changes that will occur when two accounts are merged.

ParameterVictimSurvivorFinal Values after Merging
Mobile Number/Email ID/External IDID1
ID1
Null
ID2
Null
ID2

ID2

ID1

ID2

The customer identifier will be the unique id of the surviving account if the customer id is available in both accounts.

If the customer id is not available in the surviving account, then the values will be picked from the deactivating account (if available in that account).
Registered DateD1D2
  • D1 - If D1<D2
  • D2 - If D2<D1
The earlier date among the two accounts will be considered as the final registration date.
Registered TillTill1Till2
  • Till1 - If D1<D2
  • Till2 - If D2<D1
Based on the final registered date considered, registered at till varies.
The final registration at till will be the till of the registered date considered after merging in surviving account.
Registered StoreStore 1Store 2
  • Store1 - If D1<D2
  • Store2 - If D2<D1
Based on the final registered date considered, registered at store varies.
The registered store will be the store of the earlier registered account among the two.
For example, if the registered date of the deactivating account is earlier than the registered date of surviving account then the entire registration details such as the registered date and registered at store/till/base terminal will be considered from the deactivating account.
Base TerminalT1T2
  • Terminal1 - If D1<D2
  • Terminal2 - If D2<D1

The final value will be the base terminal of the earlier registered account among the two.

For example, if the registered date of the deactivating account is earlier than the registered date of surviving account then the entire registration details such as the registered date and registered at store/till/base terminal will be considered from the deactivated account.

Customer Level Custom FieldsF1
F3
Null
F2
Null
F4
F2
F3
F4
The resultant custom fields after merging will be the custom fields of the surviving account if the custom field values are available in both accounts.
If any custom field is not available in the surviving account then the custom field value will be taken from the deactivating account (if available in that account).
TransactionsTran1Tran2Tran1+Tran2
The final transaction amount after merging will be the sum of transactions of individual accounts.
Return TransactionsRT1RT2RT1+RT2

After merging, the return transactions will be the sum of return transactions of individual accounts

Lifetime PointsLP1LP2LP1+LP2

The lifetime points after merging will be the sum of the lifetime points of individual accounts.

Current Points/Active PointsCP1CP2CP1+CP2

The current points or active points after merging will be the sum of the current points of individual accounts.

Expired PointsEP1EP2EP1+EP2

The final expired points after merging will be the sum of the total number of points expired in each account.

Redeemed PointsRP1RP2RP1+RP2 

The final redeemed points after merging will be the sum of the total number of points redeemed in each account.





We retain till id as-is in points tables. In CPS, we keep the till attribution for registration as the survivor's. The points award entry will remain connected to the till where it was originally generated. So you can achieve whatever you want.

Note:

Promised pointsPP1PP2PP1+PP2

The promised points after merging will be the sum of the promised points of individual accounts.

When the transaction is returned, the return will be processed. We don't consider who made that return. 

Imported points
IP1IP2IP1+IP2
Imported points are PACP points (Points Awarded Customer Promotions table) and will follow all the rules as mentioned in this table.
Opening points (points of third-party)
--We don't store third party points. Hence, the opening points scenarios are invalid.
Till ID of points issued


The points issued from each TILL is retained as is while merging. There will not be any change in the TILL ID associated with each set of points.
Points Expiry (Expiry schedule)Date1Date2Date1 and Date2.
Points will get expired as per the expiry schedule for points earned each time, even after merging.
For instance, if a customer has earned 300 points for purchase and assumes that the points will get expired on Aug 1, 2014, if not redeemed. Now, the customer account is merged with another account. Then, the 300 points that are transferred to the surviving account will still get expired on Aug 1, 2014, irrespective of the merge date or any other factor.
Tracker DataTracker1Tracker2The trackers for both the accounts will be combined, and the tracker condition will be calculated on the final values (values in surviving account after merging).
TierS1S2
  • If S1>S2, then S1 will be the final tier.
  • If S2>S1, then S2 will be the final tier.
  • If S1=S2, then no tier upgrade takes place.
The new tier will be the highest of the two tiers.
Tier Movement HistoryS1S2
  • If S1>S2, then S1 will be the final tier, and a new record for upgrading from S2 to S1 will be created on the retaining account.
  • If S2>S1, then S2 will be the final tier. As no tier upgrade happens in the continued account, no new record will be created in his/her account.
  • If S1=S2, then no tier upgrade takes place, and hence no additional record will be created.
Active CouponsAC1AC2AC1+AC2
The active coupons of the deactivating account will be transferred to the surviving account, enabling the customer to use all the active coupons of both accounts.
Redeemed CouponsRC1RC2RC1+RC2
All the redeemed coupons of the deactivating account will be transferred to the surviving account. This facilitates future tracking of all the redeemed coupons of the customer.
Expired CouponsEC1EC2EC1+EC2
All the expired coupons of the deactivating account will be transferred to the surviving account to keep track of all coupons that are issued to the customer and expired.
Cluster InformationC1C2The final customer data after merging will be recomputed and the cluster will be categorized as per the new figure.
For example, assume that the deactivating account is in cluster C1 and the surviving account is in cluster C2. After merging the accounts, based on the new data available cluster strategy is recalculated.
Now, if the new result meets the strategy of the cluster C3 then the surviving account after merging will be moved to the C3 cluster.
However, after merging the accounts there are chances for the customer to fall either in C1 or C2 based on the recomputed result.
NDNC StatusStatus1Status2
  • Status1 - If the mobile number of the deactivating account retains after merging,
  • Status2 - If the mobile number of the surviving account retains after merging.

NDNC status is specific to a mobile number. So, the NDNC status of the merged account depends on the mobile number that will continue to remain after merging.

For example, if the deactivating account's mobile number is retained after merging, the NDNC status will remain the same in the surviving account.

NDNC Status (When the mobile number is a secondary identifier)Registered/
Not Registered
Not Registered/
Registered
Depending on the final mobile number considered after merging, NDNC status varies.

For example, if the NDNC status of the final mobile number is registered in NDNC then the same status will continue to remain.

Opt-in Status

Whatever the communication services the surviving account has opted-in for the same will exist even after merging.
Subscription Status

Whatever is the subscription status of the surviving account, same will continue to remain after merging.
MessagesSet of
Messages1
Set of
Messages2
Set of Messages2
Messages or notifications will not be merged or transferred from the deactivating account to the surviving account. The only messages of the surviving account continue to exist even after merging.
Fraud StatusReconfirmedConfirmed/
Marked as Fraud/
Not Fraud
Reconfirmed
If the fraud status of the deactivating account is Reconfirmed then the Fraud Status of the surviving account will change to Reconfirmed.
Fraud StatusConfirmed/
Marked as Fraud/ 
Not Fraud
ReconfirmedReconfirmed
Even though the fraud status of the deactivating account is Confirmed/Marked as Fraud/ Not Fraud the surviving account's fraud status will remain Reconfirmed.
Fraud StatusConfirmedMarked as Fraud/ 
Not Fraud
Confirmed
Even though the fraud status of surviving customer is Marked as Fraud/ Not Fraud the final status after merging will be changed Confirmed.
Fraud StatusMarked as Fraud/
Not Fraud
ConfirmedConfirmed
If both accounts are in confirmed status the final value after merging also remains Confirmed.
Fraud StatusMarked as FraudNot FraudMarked as Fraud
If in any one account, the customer is marked as fraud, then the final status after merging will also be Marked as Fraud.
Fraud StatusNot FraudMarked as FraudMarked as Fraud
If in any one account, the customer is marked as fraud then the final status after merging will also be Marked as Fraud.
Fraud StatusReconfirmed/
Confirmed/
Marked as Fraud
InternalInternal
If at least one account status is internal then the final account status will be Internal.
Fraud StatusInternalConfirmed/
Marked as Fraud
Internal

If at least fraud status of merging accounts is internal then the final surviving account status will be Internal.