Merging accounts, contacts, and orders in Salesforce

From time to time you may need to merge duplicate accounts or contacts in Salesforce, or consolidate orders. When those records are connected to StoreConnect subscriptions, a merge needs care. Done incorrectly, it can stop renewals from charging, lose a saved payment method, or cancel a scheduled plan change without warning.

This article explains how StoreConnect links its records, what you can and cannot merge, and the exact fields to re-point so that renewals, upgrades, and downgrades keep working. For how StoreConnect matches customers and avoids creating duplicates in the first place, see Lead contact and account de-duplication.

:::note This article is written for Salesforce administrators and implementation partners. It refers to field API names and assumes you are comfortable working with records and lookups in Salesforce. :::

Before you begin

:::warning Always run each merge in a sandbox first, confirm the results against the checklist at the end of this article, and document the expected outcome before you touch production data. :::

A few things to know up front:

• StoreConnect does not merge records for you. It relies on the Salesforce merge to re-parent child records, and on those changes syncing back to StoreConnect.
• The Salesforce merge only supports accounts, contacts, leads, and cases. Orders cannot be merged with the native tool, so consolidating orders is a manual process.

How StoreConnect links records

Two rules govern every merge.

Keep the surviving record’s StoreConnect ID

Every StoreConnect record carries a StoreConnect ID (s_c__sC_Id__c). It is a text (external ID) field, and it is the key StoreConnect uses to join records internally. The record that survives the merge keeps its own s_c__sC_Id__c value. We will refer to this as the ‘survivor record’, and the record that does not survive the merge, as the ‘losing record’.

:::warning The Salesforce merge screen lets you choose which value survives for each field. Never select the losing record’s s_c__sC_Id__c. Always keep the surviving record’s own StoreConnect ID, or you point the survivor at the wrong StoreConnect identity. :::

Re-point every child lookup to the survivor

Salesforce relates records through lookup fields that store the 18 character Salesforce ID. After a merge, every child lookup that pointed at a losing record must point at the surviving record. When you make that change in Salesforce, StoreConnect picks it up on the next sync and re-resolves its internal link automatically.

:::note Salesforce re-points most standard relationships for you during an account or contact merge, but it does not cover everything. Custom objects, volume limits, and trigger behavior all vary, so treat the lists below as the definitive checklist of what must end up pointing at the survivor. If records sync in an unexpected order, StoreConnect reconciles the link on a later refresh rather than instantly, so always confirm the link resolved after the merge. :::

Merging accounts can delete contacts

The contact to account relationship is the only one in StoreConnect that cascades on delete.

:::warning When the losing account is deleted at the end of a merge, StoreConnect deletes any contact that still points at that account. If those contacts have not yet been re-pointed to the surviving account, they are deleted, along with their subscriptions and payment methods. :::

To merge accounts safely, re-point the losing account’s contacts to the surviving account (set Contact.AccountId to the survivor) and confirm that change has synced before the losing account is deleted. This is the highest risk step, so sequence it carefully.

Merging two contacts

Re-point each of these fields from the losing contact record to the surviving contact record.

Billing critical fields:

Object and field	Re-point to
s_c__Subscription__c.s_c__Contact_Id__c	Contact
s_c__Payment_Method__c.s_c__Contact_Id__c	Contact
Order.BillToContactId (standard)	Contact
Order.ShipToContactId (standard)	Contact

Other StoreConnect records that track the contact:

Object and field	Re-point to
s_c__Cart__c.s_c__Contact_Id__c and s_c__Ship_To_Contact_Id__c	Contact
s_c__Cart_Fulfillment__c.s_c__Ship_To_Contact_Id__c	Contact
s_c__Shipment__c.s_c__Ship_To_Contact_Id__c	Contact
s_c__Account_Credit_Ledger__c.s_c__Contact_Id__c	Contact
s_c__Account_Points_Ledger__c.s_c__Contact_Id__c	Contact
s_c__Booking__c.s_c__Contact_Id__c	Contact
s_c__Attendee__c.s_c__Contact_Id__c	Contact
s_c__Form_Submission__c.s_c__Contact_Id__c	Contact
Asset.ContactId (standard)	Contact
CampaignMember.ContactId (standard)	Contact
Lead.ConvertedContactId (standard)	Contact

:::note Order also has a custom s_c__Contact_Id__c lookup to contact that StoreConnect does not track in its sync. Re-point it in Salesforce for completeness, but note that StoreConnect uses BillToContactId and ShipToContactId as the order’s contact links. :::

There is no cascade delete on a contact merge, so any field you miss leaves an orphaned record rather than a deleted one. The subscription contact link is the one that quietly stops billing, so make sure the billing critical fields are correct.

Merging two accounts

Read the cascade warning above first, then re-point each of these fields from the losing account record to the surviving account record.

Object and field	Re-point to	Notes
Contact.AccountId (standard)	Account	This is the cascade field. See the warning above.
Order.AccountId (standard)	Account
s_c__Cart__c.s_c__Account_Id__c and s_c__Ship_To_Account_Id__c	Account
s_c__Cart_Fulfillment__c.s_c__Ship_To_Account_Id__c	Account
s_c__Shipment__c.s_c__Ship_To_Account_Id__c	Account
s_c__Account_Points_Ledger__c.s_c__Account_Id__c	Account	Master detail field with stricter reparenting rules. Handle specifically.
s_c__Booking__c.s_c__Account_Id__c	Account
Asset.AccountId (standard)	Account
Lead.ConvertedAccountId (standard)	Account

On the surviving account: be sure to preserve its s_c__sC_Id__c, and confirm its s_c__Membership_Id__c and price book are correct so entitlements stay right. See Memberships.

:::note s_c__Account_Credit__c, s_c__Account_Product_Category__c, and s_c__Location_Group_Account__c also reference the account but are not tracked by StoreConnect’s sync. If you use them, re-point them in Salesforce as well. :::

Consolidating orders

Orders cannot be merged natively, so this is a manual process. Re-point the children below, then cancel or delete the losing order record.

Billing critical fields:

Object and field	Re-point to
s_c__Subscription__c.s_c__Order_Id__c (the original order)	Order
s_c__Subscription__c.s_c__Renewal_Order_Id__c	Order
s_c__Subscription__c.s_c__Delinquent_Order_Id__c	Order
s_c__Subscription_Change__c.s_c__Order_Id__c	Order
s_c__Payment__c.s_c__Order_Id__c	Order

Other tracked fields:

Object and field	Re-point to	Notes
OrderItem.OrderId (standard)	Order
Order.OriginalOrderId (standard)	Order	Self reference
Order.s_c__Subscription_Order_Id__c	Order	Self reference
s_c__Cart__c.s_c__Order_Id__c	Order
s_c__Shipment__c.s_c__Order_Id__c	Order
s_c__Order_Campaign__c.s_c__Order_Id__c	Order	Master detail field. Handle specifically.
s_c__Discount_Credit__c.s_c__Order_Id__c	Order
s_c__Form_Submission__c.s_c__Order_Id__c	Order
s_c__Reward_Usage__c.s_c__Order_Id__c	Order
s_c__Promotion_Credit__c.s_c__Order_Id__c	Order
s_c__Promotion2_Usage__c.s_c__Order_Id__c	Order

:::tip The original order sets the subscription’s store, time zone, currency, billing and shipping address, price book, and renewal date calculations. Where possible, avoid consolidating an order that a live subscription points at. If you must, re-point every field above. :::

Values to keep intact on the subscription

These are values to preserve because they keep billing working. They are not lookups to re-point. An account or contact merge does not touch them, but you should still confirm they survive any record consolidation.

On s_c__Subscription__c:

• s_c__sC_Id__c (the StoreConnect ID)
• s_c__Payment_Token__c (the credential charged at renewal)
• s_c__Payment_Provider_Id__c
• s_c__Product_Id__c
• s_c__Period_Price__c, s_c__Period_Length__c, s_c__Period_Type__c, s_c__Period_Count__c
• s_c__Next_Billing_Date__c, s_c__Next_Renewal_Date__c
• s_c__Type__c (evergreen or fixed term)
• s_c__Charge_Payments__c

On s_c__Payment_Method__c:

• s_c__sC_Id__c, s_c__Token__c (the vault token), s_c__Payment_Provider_Id__c, s_c__Contact_Id__c, s_c__Is_Default__c, s_c__Active__c, s_c__Status__c

Products and scheduled downgrades

Subscriptions and subscription changes reference the product by its Salesforce ID, and StoreConnect does not track product relationships in its sync. A scheduled downgrade only applies at the next renewal if s_c__Subscription__c.s_c__Product_Id__c still matches the change record’s s_c__Old_Product_Id__c.

:::warning If you merge or replace products, manually re-point s_c__Product_Id__c on the affected subscriptions, and s_c__Old_Product_Id__c and s_c__New_Product_Id__c on their subscription changes, or scheduled downgrades silently fail to apply. :::

Verifying the merge

After each merge, confirm the following in your sandbox and record the before and after values:

1. Every affected subscription’s contact resolves to a live contact.
2. Saved payment methods resolve to a live contact.
3. The subscription still has its payment token.
4. A renewal charge succeeds, or simulates correctly.
5. Any recorded pending downgrade still applies at the next renewal.

:::tip If a subscription ends up orphaned, meaning its contact no longer resolves, StoreConnect does not charge it and does not notify the customer, but it does set Validation Status to invalid on the subscription and writes that back to Salesforce. Monitor the Validation Status field on s_c__Subscription__c after any merge as an early warning. :::