A Merchant-Editable Section Layer on Dawn

A custom storefront does not have to mean a developer-only storefront. The visual layer can be specific and branded while the day-to-day content stays in the hands of the team that runs the store. This is how the Absolute Support build kept routine changes inside Shopify's theme editor and product data, while the structural logic stayed engineering work.

This is the third of three deep dives from the Absolute Support case. It follows the compression PDP deep dive and the filtering deep dive.

The problem, in one paragraph

A storefront team needs to update images, copy, calls to action, and FAQs without opening theme code, and without waiting on a developer for every seasonal change. But complete no-code control is neither realistic nor desirable: some things, like navigation behavior and the shape of the underlying data, should stay in engineering hands so the store does not quietly break. The work was to draw that line deliberately, so content and structure had different, clear owners.

Constraints

• Content and structure are different jobs. Routine content should be self-serve. Structural change should be reviewed engineering work. Blurring them is how a theme turns into an unmaintainable page builder.
• Reuse over one-offs. A section built to render one exact design, once, is a liability. Sections had to be reusable across products and collections.
• Editing must stay native. The team already knows Shopify's theme editor. The right control surface was that editor, not a bespoke admin.
• No brittle references in reusable parts. A reusable section that hardcodes a specific product or collection stops being reusable the moment the catalog changes.

How the section layer is built

The content layer is built from reusable Shopify OS 2.0 sections. For readers new to Shopify: OS 2.0 sections are configurable page blocks a merchant can add, remove, and reorder in the theme editor. Each section here exposes settings (text, images, links), repeatable blocks (for lists like FAQs or feature rows), and a preset so it appears in the editor's "add section" menu. Sections choose products and collections through Shopify's native pickers rather than through hardcoded handles, and they carry sensible shared defaults so a new page looks complete before anyone customizes it. Where a product needs its own version of shared content, the section reads a product metafield override.

Content ownership: who edits what

The line between the two owners is the point of the whole design.

Merchant-editable, no developer needed:

• Images, copy, and calls to action
• FAQs and similar list content
• The specific products and collections a section shows
• Finder options and the destination collection each option points to
• Product-specific content overrides

Engineering-owned:

• Navigation behavior
• Data conventions and the metafield schema itself
• Structural layouts
• Behavior injected by apps
• New content primitives, meaning new section types

The short version, and a rule worth stating plainly: routine content changes are self-serve. Structural changes remain engineering work.

The metafield override flow

The strongest pattern in this layer is a shared section that any single product can override through its own data.

Shared section defaults       (authored)
        |
        v
Product metafield override    (merchant data, optional)
        |
        v
Product-specific content      (rendered output)

  no override present:
        |
        v
  falls back to the shared default

One shared section can serve the whole catalog. A product that needs its own image, title, badge, or body supplies it through a metafield, and the section renders that instead of the default. A product with nothing set still renders a complete baseline, so a newly added product is never blank. Crucially, the reusable section layer refers to products through data and pickers, not through hardcoded product references, which is what keeps it safe to reuse. I want to be precise here: that is a statement about the reusable section layer, not a claim that no hardcoded identifier exists anywhere in the entire theme.

The banner fallback chain

The same fallback thinking runs through the collection banner, so a collection page looks finished before anyone touches it.

Collection-specific image (set in the theme editor)
   -> else a collection metafield image
   -> else the collection's own image
   -> else a shared default image

Each step down the chain is a usable initial presentation. A merchant can override at the top when they want a bespoke banner, and ignore it entirely when they do not.

Finder configuration

The product finder is part of this editable surface too. The team can manage its labels, its options, and the destination collection each option routes to, all as section content.

What stays in engineering is the routing convention itself: the finder depends on tags and collection structure matching, so the underlying discipline of consistent naming is not something the editor can enforce. The choices are editable; the convention they rely on is maintained.

The theme editor as the control surface

Making an editor genuinely usable is a design job, not just a matter of exposing settings.

• Sections ship sensible presets, so adding one lands a working, populated block rather than an empty shell.
• Settings carry meaningful labels, so the person editing knows what each control does.
• Safe defaults mean a section is never accidentally blank.
• Not every styling decision is exposed as a setting. Over-exposing controls makes the editor harder to use, not easier, so the pixel-level styling stays in code while the content stays editable.

Editing on desktop, rendering on mobile

One honest distinction: the theme editor is largely a desktop tool, but the storefront it produces is mobile-first. Merchant editability does not guarantee mobile quality. A team can set perfectly good content and still meet a layout that needs explicit responsive handling. So the sections were built and checked for mobile rendering separately from the editing experience. Editable and mobile-correct are two different guarantees, and both had to be designed for.

What stayed structural

These stayed engineering work, not editor settings:

• Schema additions and the metafield schema
• New section types
• Navigation logic
• Layout-system changes
• App-injected behavior

Verification

Implementation-level, not a business result:

• The content layer is reusable OS 2.0 sections.
• Sections expose presets and blocks.
• Sections use native product and collection pickers.
• Product metafield overrides drive product-specific content.
• Fallback content renders when an override is absent.
• The reusable section layer holds no hardcoded product references.
• Routine content can be changed in the theme editor.

Trade-offs

• Overlapping section patterns. A few banner and education sections share most of their layout and could be consolidated into fewer parameterized sections.
• Some educational copy is fixed in code. Certain comparison content lives in the template rather than in settings, so changing that wording needs a developer.
• Section proliferation and schema complexity. More section types means more surface to maintain, and settings can grow past the point of being easy to use.
• Consolidation is future work. The reusable core is sound; the duplication is the debt to pay down.

What I would improve next

• Consolidate the duplicated education and banner patterns into fewer parameterized sections.
• Move the remaining fixed copy into settings.
• Document the editor conventions so content changes stay consistent.
• Audit empty states so no section can render blank.
• Add mobile visual regression checks so an editor change cannot quietly break a layout on a phone.

Back to the full story: the Absolute Support case.