Manage ID change requests

This page provides you with information on how to modify identifiers through the Member Care page.

You can submit the following change requests:

  • Goodwill requests (coupons and points)
  • Change mobile number
  • Change Email ID
  • Change external ID
  • Account merge
  • Edit profile
  • Delete member's account

Configure notifications, auto-approval, OTP settings , and set escalation flow

Note: This can be performed only from old Membercare

To configure Email, Mobile, External ID, or Account Merge settings, do the following:

  1. On Member Care, navigate to the Settings category and click ID Change Request Settings. You will see different change request types - Email, Mobile, External ID, Account, and Retro Transaction.
  1. Click on the option that you want to configure. You will see the corresponding options as shown below.
  1. Configure the following settings and then click Save.
OptionDescription
Email these on arrival of requestSelect the employees of your org (org POCs) that you want to notify through emails when identifier change or account merge requests are submitted - it could be through Member Care, InStore, or API. Use the Filter box to search users by name.

In Allow Request, select any of the following options.
Never: Select this if you do not want to send any alerts to org POCs.
Always: Select this to always send alerts to org POCs whenever a new request is logged.

- Only when: Select this to alert org POCs based on the transaction value of the customer.
Auto ApproveSet Auto Approve to On if you want to automatically approve Email, Mobile, External ID, or Account Merge requests, without the requests having to be queued for approval.
Communicate Change toFor Email or Mobile select whether to notify to the old identifier or new identifier and click Configure to set the notification message.
Select Old ID to send a notification to the old email id or mobile number regarding the identifier change.
Select New ID to send a notification to the new mobile number or email id.
For External ID, you can notify through both SMS and email. Click the respective CONFIGURE button to set the message.
Configure Email
(not applicable for Mobile)
1. Click the Configure button to configure the Email message.
2. In the Configure Email window, type the subject in the Subject box. In the message body, type the content and insert images. Add custom tags in the message body using the predefined tags wherever required.
3. Click Save Changes.
Configure SMS
(not applicable for Email)
1. Click the Configure button to configure the SMS message.
2. In the Configure SMS window, type in the message and include predefined tags wherever required.
OTP settings
(Applicable to all identifiers)
Set the to OTP slider to On to enable OTP validation for the customer identifier.
  1. Click Save to save the changes.

Update Identifiers Directly (One Step Change)

Org admins can update identifiers through one-step change without the need of sending for approval.

  1. Open the respective identifier change request page that you want to update - mobile, email or external id
  2. Click One Step Change.
  3. Enter the current identifier (email ID/mobile number/external ID) in the Existing box.
  4. Enter the new identifier (email ID, mobile number, or external ID) in the Requested To box.
  5. Click Proceed.

Download Identifier Change Requests

You can download ID change requests (Account Merge, Mobile Reallocation, Email, Mobile, or External ID) as a CSV file. To download the list of requests, do the following.

  1. On the respective identifier change requests 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 as a CSV file.

Delete member account

Navigate to the Membercare home page, then click the three-dots menu. From the ID change request dropdown, select Delete member's account and submit the request.

After a deletion request is raised for a customer, their status changes to Deletion Pending. The member account is deleted only after the deletion request is approved. For information on approving or rejecting a request, refer to Manage requests.

Merge Accounts

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.

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.
  • Check Requestor to notify the customer that requested for account merge.
  • Check Survivor to notify the customer whose remains after merging.
  • Check both Requestor and Survivor to notify both.
  1. To configure SMS notification, click the Configure button next to Configure SMS and create the message. Use predefined tags wherever required.
  2. To configure email, click the Configure button next to Configure Email.
  • In Subject, enter the subject of the email.
  • 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.
  • Click Save Changes.
  1. 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 TillTill1Till2Till1 - 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.
Till IDWe 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.
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.
Imported pointsIP1IP2IP1+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 issuedThe 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 StatusStatus1Status2Status1 - 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 StatusWhatever the communication services the surviving account has opted-in for the same will exist even after merging.
Subscription StatusWhatever 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.
Card detailsC2C2C1 & C2. The cards of the victim are transferred to the survivor's account.
Transaction requestsTransaction Request 1Transaction Request 2Transaction request 1 & 2. The pending transaction requests of the victim are transferred to the survivor.

❗️

When merging cards with the survivor, the application may generate warnings in the following scenarios:

  1. If the total number of cards under the survivor exceeds the defined maximum number of active cards per customer for individual card types.
  2. If the total number of cards under the survivor exceeds the defined maximum number of active cards based on global card settings.

However, you can choose to ignore the warning and proceed with adding the cards to the survivor.

Excluding card merging during account merge

By default, when merging customer accounts, the cards associated with the victim account are transferred to the survivor account automatically. In case the customer exceeds the set threshold for the maximum number of cards they can hold, the transfer of cards from a victim to a survivor account will proceed with a warning.
However, if you want do not want to transfer the cards of the victim account to the survivor account during a customer merge, you can raise a ticket and disable the CONF_ALLOW_CARD_TRANSFER_TO_SURVIVOR configuration. This ensures that the cards are not transferred along with the other existing parameters.

❗️

There is no UI to enable this configuration. You need to raise a JIRA ticket (sample ticket) to the sustenance team to enable these configurations. Turn around time is five days.