{"title":"How stores, themes, and design elements relate","slug":"how-stores-themes-and-design-relate","url":"https://support.storeconnect.com/articles/how-stores-themes-and-design-relate","url_markdown":"https://support.storeconnect.com/articles/how-stores-themes-and-design-relate.md","subtitle":null,"summary":"Understand which records control how a StoreConnect storefront looks, how a store connects to its theme, templates, pages, content blocks, and menus, and which record to change to affect a given part of the page.","type":"Developer_Documentation","video_url":"","keywords":"store, theme, theme template, content block, page, menu, style block, script block, media, data model, relationships, storefront design, which record, salesforce objects, design elements","last_modified":"2026-08-21T07:12:35+0000","body_markdown":"Several different records decide how a StoreConnect storefront looks, and they\nare not arranged in one chain. A theme controls the markup. Pages and content\nblocks hold the words and images. Menus hold navigation. The **Store** record\nties them together and overrides pieces of them.\n\nUse this article to work out which record to change to affect a given part of a\npage, and to understand why a setting you expect to find on the theme is on the\nstore instead.\n\n## The store is the hub\n\nEverything starts at the [Store](store-object-reference) record. It points at one\ntheme, and separately at the individual records that fill in the parts of the\npage the theme leaves open.\n\n```\nStore\n├── Theme_Id__c ─────────────► Theme\n├── Header_Menu_Id__c ───────► Menu\n├── Footer_Menu_Id__c ───────► Menu\n├── Home_Page_Id__c ─────────► Page\n├── Terms_Page_Id__c ────────► Page\n├── Header_Content_Block_Id__c ──► Content Block\n├── Footer_Content_Block_Id__c ──► Content Block\n├── Head_Content_Block_Id__c ────► Content Block\n├── Body_Content_Block_Id__c ────► Content Block\n├── Logo_Id__c / Favicon_Id__c / Social_Image_Id__c ──► Media\n└── Product_Placeholder_Id__c / Category_Placeholder_Id__c ──► Media\n```\n\nThis is the part that surprises people. The header and footer are not theme\nfiles; they are content blocks selected on the store. Two stores can share a\ntheme and still have different headers, and changing the header on one store\ndoes not touch the other.\n\n## The theme owns the markup\n\nA [Theme](theme-object-reference) record is almost empty by itself. It has a name\nand little else. What matters are the four kinds of record that point at it:\n\n| Record | Holds | Article |\n|--------|-------|---------|\n| **Theme Template** | Liquid markup, one record per template, identified by **Key** | [Theme Template](theme-template-object-reference) |\n| **Theme Asset** | CSS, JavaScript, fonts, and images | [Theme Asset](theme-asset-object-reference) |\n| **Theme Variable** | Key-value settings the templates read | [Theme Variable](theme-variable-object-reference) |\n| **Theme Locale** | Translation strings | [Theme Locale](theme-locale-object-reference) |\n\nAll four carry a `s_c__Theme_Id__c` lookup. That is the whole theme model: the\n**Theme** record is a container, and its content lives in the records pointing\nback at it.\n\nA theme does not need to be complete. Any template it does not supply falls back\nto the built-in base theme, which is why a brand-new theme renders a working\nstorefront. See [theme structure](theme-structure) for the template keys and how\nthat fallback resolves.\n\n## Pages and content blocks\n\nA [Page](page-object-reference) holds a route and its own body. Content blocks\nare the reusable pieces placed onto it, and they attach through a junction rather\nthan a direct field:\n\n```\nPage ◄── Content Block Page ──► Content Block ◄── Content Block Child ──► Content Block\n```\n\nLooking at [Content Block](content-block-object-reference) alone, you will find\nlookups to **Media** and nothing pointing at a page. The placement lives on\n[Content Block Page](content-blocks-pages-object-reference), one record per\nblock-on-a-page, each with its own **Position**. The same block can therefore\nappear on many pages in a different order on each.\n\nThe same pattern attaches blocks to products, categories, and articles, and\n[Content Block Child](content-blocks-children-object-reference) nests blocks\ninside other blocks. [Junction objects](junction-objects) explains the pattern and\nlists them all.\n\n## Menus, styles, and scripts\n\n[Menu](menu-object-reference) records hold [Menu Item](menu-item-object-reference)\nrecords, and a menu item can nest inside another menu item to build a dropdown.\nThe store chooses which menu is the header and which is the footer.\n\n[Style Block](style-block-object-reference) and\n[Script Block](script-block-object-reference) both attach to the **Store**, not\nthe theme. They are how you add CSS or JavaScript to one store without editing a\nshared theme.\n\n## Which record do I change?\n\n| To change | Edit |\n|-----------|------|\n| Page structure and markup | A **Theme Template** on the theme |\n| Colors, fonts, spacing | A **Theme Asset** (`theme-supplement.css`), or a **Style Block** for one store |\n| Text or images in a page region | The **Content Block** placed there |\n| What appears in the header or footer | The content block the **Store** points at |\n| Navigation links | The **Menu** the store points at, and its **Menu Items** |\n| Wording of a built-in label | A **Theme Locale** on the theme |\n| A setting a template reads | A **Theme Variable** on the theme |\n| Logo, favicon, placeholder images | The **Media** records the **Store** points at |\n| Which theme a store uses | **Theme** on the **Store** record |\n\n## Why the split matters\n\nThemes are shared; stores are not. Anything that should differ between two stores\nrunning the same theme has to live on the store, which is why the header content\nblock, menus, logo, and style blocks are all store-level. Anything that defines\nhow the storefront is built lives on the theme, so improving a template improves\nevery store using it.\n\nWhen you are deciding where to put something, ask whether a second store on the\nsame theme should get it automatically. If yes, it belongs on the theme. If no,\nit belongs on the store.\n\nYou should now be able to take any visible part of a storefront and name the\nrecord that controls it, and use the **Referenced by** table on any object\nreference article to see what else points at it."}