Skip to main content

Visual Builder Mode

Mode tab: Builder — the studio's default, if you hold Build Public Pages.

Builder mode is a three-panel workspace: the palette on the left, the canvas in the middle, and — once you select something — the inspector on the right.

Figure 1 — Palette (230px) and canvas. The inspector column appears only when a block is selected.

1. Above the canvas​

Three controls sit above the builder and apply to the whole page.

Figure 2 — Two independent toggles: the header and the footer are chosen separately.
ModeWhat it meansUse it for
Shared (default)The page follows the store-wide chrome from Store Settings / Experience Manager. It carries no header container of its own.Almost every page — home, category, product, account, help, blog. Change the global menu once and every Shared page follows.
CustomThe page detaches from the global chrome and carries its own header/footer containers on the canvas.Campaign landings, funnels, distraction-free checkouts.

The bar states the rule in situ: "Shared = the page follows the store-wide chrome from Store Settings. Custom = this page carries its own, editable in the builder."

Switching to Custom is a one-way copy

Adding custom chrome stops the page following the shared version — a toast says so and reminds you to Save Draft to keep it. Restoring Shared discards the custom containers. Global menu edits will not reach a Custom page.

Custom display name​

An optional per-language override for the page's display name. Leave it empty and the page's own name is used.

Route / slug override​

Figure 3 — The final URL is computed live as you type.

The card shows the fixed URL prefix, an editable slug, and underneath: Final URL and Default slug. A DEFAULT badge in the corner means nothing is overridden.

Do not override the slug on a page whose route takes a parameter

Some system pages are served by routes with a path parameter — a product detail page, an article page. Setting a slug override on one of those stops its route pattern matching and the public page starts returning 404. Leave those on their default slug.


2. The palette​

Figure 4 — The palette for a CART page: 4 containers, 13 components, 5 widgets.

Headed ADD TO CANVAS, with a vertical rail of three groups down the left edge and a live count on each:

GroupWhat it holds
ContainersThe structural blocks that hold components — main content, header, footer, column rows.
ComponentsThe content blocks — Rich Text, Image, Button, Cart Summary, CTA Banner, Divider…
WidgetsFloating overlay blocks, pinned to a screen corner.

Filter… searches by name, kind or category across all three groups.

Every row has a ? button opening that block's own help.

The palette is page-type specific

The counts are not fixed. A page's page type decides which blocks are offered — a CART page gets Cart Summary and Related Products; a blog page gets different ones. If a block you expect is missing, the page type is why. A page with no page type set shows an amber warning and no palette at all, and a platform admin has to assign one in /admin/customerpages.


3. The canvas — zones, containers, components​

Figure 5 — The zone model. Each zone shows how many containers it holds.

The canvas is not a flat list of blocks. It has three levels:

#ZoneHolds
1Top zoneThe header container.
—Left zone / Right zoneOptional sidebars. Empty by default: "Drop a container here."
2Center / Main contentThe page's real content.
3Bottom zoneThe footer container.
4Floating widgetsCorner-pinned overlays — WhatsApp button, back-to-top, cookie consent. Listed as chips, not stacked in a zone.

Each zone's heading shows a count of the containers in it, so an empty region is obvious at a glance.

Containers accept components; zones accept containers. Dropping a component straight into an empty zone does not work — that is what the "Drop a container here" versus "Drop content components here" hints are telling you.

Row controls​

Every block row carries, left to right: a drag handle (⠿) for reordering, the block's name and its code (cart_summary, header · top), and a bin to remove it. Some components add a settings icon.

Click anywhere on a row to select it — that is what opens the inspector.

Fullscreen in the section header expands the builder to the whole window.

A brand-new page offers you a template

An empty page shows a "New page — start from a template" prompt: pick a ready-made starter layout, or scaffold a blank layout with just the standard chrome. Applying a template brings sample data with it — the toast tells you to click each block and fill in your own content, then Save Draft.


4. The inspector​

Figure 6 — The inspector for a Cart Summary block.

Select a block and a third column opens, headed INSPECTOR · IN <CONTAINER> so you always know where the block lives. It has three parts, in this order:

Alignment — Left · Center · Right. On a block inside a header, footer or bar this is joined by a Width control.

The block's own settings — whatever that component exposes. A Cart Summary offers Heading, Show item thumbnails, checkout button label and link, continue-shopping label and link, and a whole empty-state group (title, subtitle, CTA label, CTA link). A Rich Text block offers something completely different. This section is the component's own contract, which is what the component guides document.

Visibility — three choices, not per-breakpoint switches:

OptionEffect
Always (default)Rendered everywhere.
Hide mobileHidden on small screens.
Hide desktopHidden on large screens.
There is no tablet option, and no theme-token panel

Visibility is a single three-way choice — there is no separate tablet setting. Nor does the inspector carry colour swatches, container-width dropdowns or padding sliders: page-wide look comes from Brand Identity, and per-block appearance from whatever fields that component itself exposes.

Clicking empty canvas space clears the selection and closes the inspector.