{"title":"Merging accounts, contacts, and orders in Salesforce","slug":"merging-accounts-contacts-and-orders","url":"https://support.storeconnect.com/articles/merging-accounts-contacts-and-orders","url_markdown":"https://support.storeconnect.com/articles/merging-accounts-contacts-and-orders.md","subtitle":null,"summary":"How to merge duplicate accounts, contacts, and orders in Salesforce without breaking StoreConnect subscriptions, saved payment methods, or renewals.","type":"Help_Documentation","video_url":"","keywords":"merge, merging, duplicate records, deduplication, salesforce, subscriptions, renewals, payment methods, data integrity","last_modified":"2026-07-30T00:28:16+0000","body_markdown":"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.\n\nThis 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](lead-contact-and-account-deduplication).\n\n:::note\nThis 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.\n:::\n\n## Before you begin\n\n:::warning\nAlways 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.\n:::\n\nA few things to know up front:\n\n- 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.\n- 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.\n\n## How StoreConnect links records\n\nTwo rules govern every merge.\n\n### Keep the surviving record's StoreConnect ID\n\nEvery 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'.\n\n:::warning\nThe 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.\n:::\n\n### Re-point every child lookup to the survivor\n\nSalesforce 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.\n\n:::note\nSalesforce 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 use the lists below to confirm everything that 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.\n:::\n\n## Merging accounts can delete contacts\n\nThe contact to account relationship is the only one in StoreConnect that cascades on delete.\n\n:::warning\nWhen 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.\n:::\n\nTo 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.\n\n## Merging two contacts\n\nRe-point each of these fields from the losing contact record to the surviving contact record.\n\nBilling critical fields:\n\n| Object and field | Re-point to |\n|---|---|\n| `s_c__Subscription__c.s_c__Contact_Id__c` | Contact |\n| `s_c__Payment_Method__c.s_c__Contact_Id__c` | Contact |\n| `Order.BillToContactId` (standard) | Contact |\n| `Order.ShipToContactId` (standard) | Contact |\n\nOther StoreConnect records that track the contact:\n\n| Object and field | Re-point to |\n|---|---|\n| `s_c__Cart__c.s_c__Contact_Id__c` and `s_c__Ship_To_Contact_Id__c` | Contact |\n| `s_c__Cart_Fulfillment__c.s_c__Ship_To_Contact_Id__c` | Contact |\n| `s_c__Shipment__c.s_c__Ship_To_Contact_Id__c` | Contact |\n| `s_c__Account_Credit_Ledger__c.s_c__Contact_Id__c` | Contact |\n| `s_c__Account_Points_Ledger__c.s_c__Contact_Id__c` | Contact |\n| `s_c__Booking__c.s_c__Contact_Id__c` | Contact |\n| `s_c__Attendee__c.s_c__Contact_Id__c` | Contact |\n| `s_c__Form_Submission__c.s_c__Contact_Id__c` | Contact |\n| `Asset.ContactId` (standard) | Contact |\n| `CampaignMember.ContactId` (standard) | Contact |\n| `Lead.ConvertedContactId` (standard) | Contact |\n\n:::note\n`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.\n:::\n\nThere 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.\n\n## Merging two accounts\n\nRead the cascade warning above first, then re-point each of these fields from the losing account record to the surviving account record.\n\n| Object and field | Re-point to | Notes |\n|---|---|---|\n| `Contact.AccountId` (standard) | Account | This is the cascade field. See the warning above. |\n| `Order.AccountId` (standard) | Account | |\n| `s_c__Cart__c.s_c__Account_Id__c` and `s_c__Ship_To_Account_Id__c` | Account | |\n| `s_c__Cart_Fulfillment__c.s_c__Ship_To_Account_Id__c` | Account | |\n| `s_c__Shipment__c.s_c__Ship_To_Account_Id__c` | Account | |\n| `s_c__Account_Points_Ledger__c.s_c__Account_Id__c` | Account | Master detail field with stricter reparenting rules. Handle specifically. |\n| `s_c__Booking__c.s_c__Account_Id__c` | Account | |\n| `Asset.AccountId` (standard) | Account | |\n| `Lead.ConvertedAccountId` (standard) | Account | |\n\nOn 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](memberships).\n\n:::note\n`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.\n:::\n\n## Consolidating orders\n\nOrders cannot be merged natively, so this is a manual process. Re-point the children below, then cancel or delete the losing order record.\n\nBilling critical fields:\n\n| Object and field | Re-point to |\n|---|---|\n| `s_c__Subscription__c.s_c__Order_Id__c` (the original order) | Order |\n| `s_c__Subscription__c.s_c__Renewal_Order_Id__c` | Order |\n| `s_c__Subscription__c.s_c__Delinquent_Order_Id__c` | Order |\n| `s_c__Subscription_Change__c.s_c__Order_Id__c` | Order |\n| `s_c__Payment__c.s_c__Order_Id__c` | Order |\n\nOther tracked fields:\n\n| Object and field | Re-point to | Notes |\n|---|---|---|\n| `OrderItem.OrderId` (standard) | Order | |\n| `Order.OriginalOrderId` (standard) | Order | Self reference |\n| `Order.s_c__Subscription_Order_Id__c` | Order | Self reference |\n| `s_c__Cart__c.s_c__Order_Id__c` | Order | |\n| `s_c__Shipment__c.s_c__Order_Id__c` | Order | |\n| `s_c__Order_Campaign__c.s_c__Order_Id__c` | Order | Master detail field. Handle specifically. |\n| `s_c__Discount_Credit__c.s_c__Order_Id__c` | Order | |\n| `s_c__Form_Submission__c.s_c__Order_Id__c` | Order | |\n| `s_c__Reward_Usage__c.s_c__Order_Id__c` | Order | |\n| `s_c__Promotion_Credit__c.s_c__Order_Id__c` | Order | |\n| `s_c__Promotion2_Usage__c.s_c__Order_Id__c` | Order | |\n\n:::tip\nThe 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.\n:::\n\n## Values to keep intact on the subscription\n\nThese 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.\n\nOn `s_c__Subscription__c`:\n\n- `s_c__sC_Id__c` (the StoreConnect ID)\n- `s_c__Payment_Token__c` (the credential charged at renewal)\n- `s_c__Payment_Provider_Id__c`\n- `s_c__Product_Id__c`\n- `s_c__Period_Price__c`, `s_c__Period_Length__c`, `s_c__Period_Type__c`, `s_c__Period_Count__c`\n- `s_c__Next_Billing_Date__c`, `s_c__Next_Renewal_Date__c`\n- `s_c__Type__c` (evergreen or fixed term)\n- `s_c__Charge_Payments__c`\n\nOn `s_c__Payment_Method__c`:\n\n- `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`\n\n## Products and scheduled downgrades\n\nSubscriptions 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`.\n\n:::warning\nIf 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.\n:::\n\n## Verifying the merge\n\nAfter each merge, confirm the following in your sandbox and record the before and after values:\n\n1. Every affected subscription's contact resolves to a live contact.\n2. Saved payment methods resolve to a live contact.\n3. The subscription still has its payment token.\n4. A renewal charge succeeds, or simulates correctly.\n5. Any recorded pending downgrade still applies at the next renewal.\n\n:::tip\nIf 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.\n:::"}