How the StoreConnect data model fits together

StoreConnect installs around 200 Salesforce objects. Read individually they are hard to place, because the schema is wide rather than deep: a handful of objects carry most of the relationships, and everything else hangs off them.

Use this article to get oriented before you go looking for a specific object, and to learn the conventions that let you predict what an object looks like before you open it.

:::note If you are new to Salesforce objects and fields, read StoreConnect and Salesforce objects and fields first. It covers what objects, fields, and relationships are, how StoreConnect extends the eleven standard objects it uses, and the custom field limits that apply. This article assumes that and concentrates on navigating the reference.

To explore the same model visually, the StoreConnect Console has a built-in Schema Explorer: an interactive entity relationship diagram covering every object and how they connect. :::

Reading any object’s page

Every object reference article has the same sections, and the last two are the ones people miss:

Section	Answers
Overview	What the object is, and its API name
Fields	Every field, its type, and whether it is required
Relationships	What this record points at
Referenced by	What points at this record
On the storefront	The Liquid object that renders it, and which field arrives as which attribute

On the storefront is the crossing into Liquid. It saves guessing at a drop name, because a Salesforce object and its Liquid object are not named the same thing: Product2 is product in a template. To go from a field to the template code that renders it, see show a Salesforce field on the storefront.

Relationships and Referenced by are the two directions of the same question, and you usually need the second one. If you are asking “what is related to this?”, read Referenced by. Its Also links to column names what a join record connects to on its far side, so you can follow a relationship through a junction without opening it.

Naming conventions

Everything the package installs carries the s_c__ namespace. Beyond that, three conventions make most of the schema predictable.

• A lookup field ends in _Id__c. s_c__Store_Id__c points at the store, s_c__Product_Id__c at a product. There are 180 of them. If you are looking for the link between two objects, search for the target’s name followed by _Id__c.
• s_c__sC_Id__c is the sync key. 148 objects carry it. It is a GUID StoreConnect owns, used to match records between Salesforce and the storefront database. Use it as the external ID when importing, and never edit it by hand.
• Junction objects are named after both sides. Product_Tag__c, Zone_Country__c, Content_Blocks_Pages__c. See junction objects.

The shape of the schema

A few objects carry a disproportionate share of the relationships. Knowing which ones tells you where to start reading.

Object	Records pointing at it	What it anchors
Store	40	Nearly all configuration. 39 objects carry a store lookup
Product2	39	The catalog, and most commerce
Media	26	Every image, file, and document
Account	22	Customers, suppliers, and brands
Contact	18	People, and storefront sign-in
Product Category	15	Catalog structure
Order	14	Everything after checkout

Store is the one to understand first. Almost anything configurable is either on the store record or on an object that points at it, which is what makes a single Salesforce org able to run several storefronts with different catalogs, themes, and payment providers.

Functional areas

The custom objects group into a few areas. This is a reading aid rather than anything the schema enforces:

Six of them have their own article, naming every object in the area and the relationships that matter:

• Catalog objects — products, categories, variants, bundles, traits, media, pricing
• Order and checkout objects — carts, orders, payments, subscriptions, vouchers, promotions, discounts, tax
• Store design objects — stores, themes, pages, content blocks, menus, style and script blocks
• Fulfillment and inventory objects — shipments, stock levels and locations, transfers, shipping rates, zones
• POS objects — outlets, registers, shifts, POS layouts and actions, print templates
• Customer and account objects — accounts, contacts, memberships, credit, points, approvals

Two areas have no article of their own. Content is articles, article categories, and tags. Platform is sync records, custom data mappings, error definitions, and settings. Bookings and forms sit outside the six as well. Custom objects lists everything.

For the store and design area, how stores, themes, and design elements relate explains which record controls what; store design objects is the object inventory.

Finding your way

When you need to know how two objects connect:

1. Open the object reference for either one.
2. Check Relationships for a direct lookup to the other.
3. If it is not there, check Referenced by — the link is often on a third record that points at both. The Also links to column names it.
4. If the connecting record is a junction, junction objects explains what that means for querying, importing, and deleting.

Most “there is no relationship between these” conclusions turn out to be a junction one step away.