# StoreConnect Support 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](lead-contact-and-account-deduplication). :::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](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. ::: --- ## Follow StoreConnect - [Email Newsletter](https://getstoreconnect.com/c/lp-newsletter) - [LinkedIn Newsletter](https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7444956928444862464) - [YouTube](https://www.youtube.com/channel/UCngKdP2x8l1wcbAKW3tvU8g) - [LinkedIn](https://www.linkedin.com/company/storeconnect) - [X / Twitter](https://x.com/storeconnecthq) ## Popular Links - [Partners](https://getstoreconnect.com/partners) - [News](https://getstoreconnect.com/articles/news) - [Events](https://getstoreconnect.com/articles/events) - [Feature Comparison](https://getstoreconnect.com/how-we-compare) - [Download a free trial](https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FMkeKUAT) - [Book a Demo](https://getstoreconnect.com/contact) ## Documentation - [Help documentation](https://support.storeconnect.com/help-documentation) - [Videos & tutorials](https://support.storeconnect.com/videos-tutorials) - [Developer reference](https://support.storeconnect.com/developer-reference) - [Release notes](https://support.storeconnect.com/release-notes) - [Troubleshooting](https://support.storeconnect.com/troubleshooting) - [Trust Center](https://trust.getstoreconnect.com/) - [Status Page](https://status.storeconnect.com/) ## Contact - info@getstoreconnect.com - US +1 415 745 3230 - AUS +61 2 8365 2308 100 S Ashley Dr, Suite 600-2461 Tampa FL 33602-600 USA Level 22, Sydney Place 180 George Street Sydney, NSW, 2000, AUS --- StoreConnect Support — https://support.storeconnect.com