Manage ID change requests

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.

2. Click on the option that you want to configure. You will see the corresponding options as shown below.

3. Configure the following settings and then click Save.

4. 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.

📘

Note

In connected organizations, if a user registers in a different child org using the same primary or secondary identifier, the system merges their profiles in the parent org and then synchronizes those merged changes back to each child org.

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.

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.

• 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.

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
• Rewards: All rewards 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.

❗️

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.

📘

Note

When merging accounts , CONF_MERGE_POINTS_LEDGER can be enabled to preserve detailed points history when merging customer details. To enable this, raise a JIRA ticket to product support.

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.

Skipping secondary identifiers when merging user data

You can use the CONF_SKIP_SECONDARY configuration to determine whether to skip using secondary identifiers when merging user data. If enabled, the system will not use secondary identifiers when a matching user is found; instead, it will only consider the primary identifier.

The section below explains the scenarios when the configuration is enabled and disabled.

Terms

• Campaign user - An individual whose identifiers are present in Capillary's Campaign users' list, used for sending campaign messages.
• Loyalty user: An individual who is already a customer and enrolled into a loyalty program.
• Incoming transaction: An incoming transaction from a new or existing customer.

CONF_SKIP_SECONDARY is disabled

When CONF_SKIP_SECONDARY is disabled, the campaign user will merge with the loyalty user based on matches with the primary identifier or any other identifier.

Example 1:

Primary Identifier - Mobile

Primary Identifier (Mobile) Match:

• The system compares the Mobile identifiers.
• Campaign User has Mobile (M1) and the incoming request has Mobile (M2).

Merge Decision:

• The Campaign User's existing details (Email: E1, Mobile: M1) will be updated to Email: E1, Mobile: M2.
• Depending on the payload passed, this updated user will be considered a loyalty or non-loyalty user.

Example 2:

Primary identifier - mobile

Matching Process:

Primary Identifier (Mobile) Matching:

• The system compares the primary identifier (Mobile).
• Campaign User has Mobile: M1, but the request has Mobile: M2.
• Loyalty User has Mobile: M2, which matches with the request.

Secondary Identifier (Email) Matching:

• Incoming user data's Email (E1) matches the Campaign User's Email (E1).
• However, the merge is primarily driven by the primary identifier (Mobile).

Merge Process:

• Since CONF_SKIP_SECONDARY is disabled, the merge considers both primary and secondary identifiers.
• Campaign User (Email: E1, Mobile: M1) and Loyalty User (Email: NULL, Mobile: M2) are merged.

Result:

• Campaign user's Email remains NULL, and Mobile remains M1: Email(NULL), Mobile(M1).

• Loyalty user's Email is updated to E1, and Mobile remains M2: Email(E1), Mobile(M2).

  After Merging

📘

Note

If the survivor user's email or mobile is Null (Loyalty user), then the victim (Campaign user) user's email or mobile will merge into a survivor.

Example 3:

Primary identifier - mobile

Primary Identifier (Mobile) Match:

• The system compares the Mobile identifiers.
• Campaign User has Mobile (M2) and the incoming request has Mobile (M2).

Merge process

The merge occurs because the mobile (M2) of the campaign user matches the corresponding data in the incoming transaction user data(M2), and the email (E1) of the loyalty user matches the corresponding data in the incoming transaction user data(E1).

After Merging

📘

Note

• If the survivor (Loyalty user) user's email or mobile is null, then the victim (Campaign user) user's email or mobile will merge into the survivor.
• The loyalty user's email remains the same as E1 and mobile changes to M2 because the victim details will be merged into a survivor.

CONF_SKIP_SECONDARY is Enabled

When CONF_SKIP_SECONDARY is enabled, the system skips secondary identifiers during the merging process of campaign and loyalty users. In this scenario, merging will not happen based on secondary identifier matches alone. Instead, merging relies on primary identifier matches between campaign and loyalty users.

Example 1:

Primary Identifier - Mobile

Matching Process:

• Since CONF_SKIP_SECONDARY is enabled, the system ignores the secondary identifier (Email) and only considers the primary identifier (Mobile).The Campaign User has Mobile: M1, which does not match the incoming request's Mobile: M2.

Merge Process:

• No existing user with Mobile: M2 is found in the database.
• Since the primary identifier (Mobile) does not match any existing user, no merge happens with the Campaign User.
• A new loyalty user is created with the provided primary identifier (Mobile: M2).

Result:

• Campaign User: Remains unchanged: Email: E1, Mobile: M1.
• New Loyalty User: Created with: Email: NULL, Mobile: M2 (since the incoming request's primary identifier is M2, and secondary identifiers are ignored).

After Merging

Example 2:

Primary Identifier - Mobile

Matching Process: Primary Identifier (Mobile) Matching:

The system looks at the primary identifier (Mobile). Customer 3 has Mobile: M2, which matches with the Loyalty User's Mobile: M2.

Secondary Identifier (Email) Matching: Even though CONF_SKIP_SECONDARY is enabled, Customer 3's Email: E1 matches the Campaign User's Email: E1. However, the merge is primarily driven by the primary identifier (Mobile).

Merge Process: Since CONF_SKIP_SECONDARY is enabled, the merge is based on the primary identifier. Customer 3 (Email: E1, Mobile: M2) matches with both the Campaign User (Email: E1, Mobile: M1) and the Loyalty User (Mobile: M2).

Result: The merge happens because the primary identifier (Mobile) matches. Campaign User (Email: E1, Mobile: M1) and Loyalty User (Mobile: M2) are merged.

After Merging

📘

Note

If the survivor user (Loyalty User) has NULL in either email or mobile, the corresponding field from the victim user (Campaign User) will be merged into the survivor. In this case, since the Loyalty User's Email was NULL, it is updated to E1 from the Campaign User.

Example 3:

Primary Identifier - Mobile

Primary Identifier Matching:

• The primary identifier is Mobile.
• Customer 3 has Mobile: M2, which matches Customer 1's Mobile: M2.

Secondary Identifier Matching:

• Customer 3 has Email: E1, which matches Customer 2's Email: E1.
• Since CONF_SKIP_SECONDARY is enabled, secondary identifiers should generally be ignored. However, in this case, secondary identifiers still cause a conflict due to the match.

Merging process:

• The system identifies that Customer 3's Email (E1) matches Customer 2's Email, and Mobile (M2) matches Customer 1's Mobile. The system gives preference to the Loyalty user (Customer 2).
• The attempt to add Customer 3 fails because there is a conflict with existing users, and preference is given to the Loyalty user where the primary identifiers are not a match.

Result:

Example 4:

Primary Identifier - Mobile

Matching Process:

Primary Identifier (Mobile) Matching:

• The system considers the primary identifier (Mobile).
• Customer 3 has Mobile: M2, which matches with the Loyalty User's Mobile: M2.

Secondary Identifier (Email) Matching:

• Despite CONF_SKIP_SECONDARY being enabled, Customer 3's Email: E1 matches the Campaign User's Email: E1.
• However, the merge primarily relies on the primary identifier (Mobile).

Merge Process:

• Due to CONF_SKIP_SECONDARY being enabled, the merge is based on the primary identifier.
• Customer 3 (Email: E1, Mobile: M2) matches both the Campaign User (Email: E1, Mobile: M1) and the Loyalty User (Mobile: M2).

Result: The merge occurs because the primary identifier (Mobile) matches. The Campaign User (Email: E1, Mobile: M1) and the Loyalty User (Mobile: M2) are merged.

After Merging

Skipping custom and extended fields during customer merge

By default, the custom fields and extended fields are merged during a customer merge process. You can control whether custom fields or extended fields need to be merged using the CONF_SKIP_MERGE_HANDLER configuration.

• To skip merging custom fields, set the configuration value to CUSTOM_FIELDS.
• To skip merging extended fields, set the configuration value to EXTENDED_FIELDS. This applies to extended field data for the CUSTOMER entity type.

Enabling the configuration

To enable this configuration, raise a JIRA ticket with the Capillary Product Support team.

Handling common extended fields during customer merge

The CONF_CUSTOMER_MERGE_OVERWRITE_EXTENDED_FIELD_VALUE configuration controls how conflicting extended fields are handled when both the survivor and victim profiles have the same field extended field names with different values.

• If set to false(default):
  • The survivor's values for common extended fields are retained.
  • Only non-conflicting extended fields from the victim are added to the survivor profile.
• If set to true:
  • The victim’s values for common extended fields overwrite the survivor’s values.
  • Non-conflicting extended fields from the victim are still added to the survivor profile.

Merge behavior scenarios

Blocking redemptions for victim users

When you merge customer accounts, the victim account becomes inactive while its data transfers to the survivor account. The CONF_REJECT_REDEMPTION_FOR_VICTIM_USERS configuration blocks all redemption attempts for victim users.

When enabled, the system prevents redemptions of coupons, points, rewards, and other loyalty benefits for customers whose accounts have been merged into a survivor account.

How it works

When a redemption request is made:

• The system checks if the customer is a victim user.
• If they are a victim user and CONF_REJECT_REDEMPTION_FOR_VICTIM_USERS is enabled, the redemption is rejected
• If disabled (default), the redemption is automatically redirected to the survivor account

To enable this configuration, raise a JIRA ticket with the Capillary Product Support team.