Author and developer tasks
Labels, block settings, spacing, and scheduling are all author tasks done in Document Authoring without code. Visual design and behavior inside a drop-in (colors, layout, how buttons work) belongs to a developer.
What you can change without code
Section titled “What you can change without code”Use tables and sheets in Document AuthoringThe tooling for creating storefront pages as documents in Google Docs, SharePoint, or DA.live without writing code. Tables in documents define the blocks that appear on each page.:
| Task | Where to do it | Reference |
|---|---|---|
| Choose which Commerce block appears on a page | The block table on the page | Block table structure |
| Set the few settings a Commerce block accepts | The block table on the page | The Commerce block’s reference page in B2C Commerce blocks or B2B Commerce blocks |
| Change the words shoppers see (button labels, headings, messages) | The placeholders sheet for the matching drop-in | Labels and placeholders |
| Set the page title, description, and indexing | The metadata table on the page | Page metadata |
| Adjust spacing, background, and column widths around a Commerce block | A section-metadata table after the Commerce block | Section metadata |
| Translate labels into other locales | The locale-specific placeholders sheets | Commerce localization tasks |
| Add related blocks on the same page (for example, breadcrumbs or Product Recommendations) | Add another block table on the page | Using Content and Commerce blocks |
| Schedule when a page goes live | Snapshot scheduling in Document Authoring | Scheduling options |
What needs a developer
Section titled “What needs a developer”These changes require code or configuration outside the author tools:
| Task | Why it is not an author task |
|---|---|
| Add or remove an element inside a drop-in (for example, a wishlist button on the product page) | That element is part of the drop-in layout code, not your block table. A developer adds or removes it there. |
| Change the visual design of a drop-in (colors, fonts, button shapes beyond section metadata) | Visual design lives in your storefront’s CSS and shared style settings. A developer edits those files. |
| Track a new event in analytics or A/B testing | Drop-ins send events that other code can listen for. A developer connects those events to your analytics tool (for example, Google Analytics or Adobe Target). |
| Connect or change your storefront’s connection to Adobe Commerce (endpoints, store view headers, services) | These settings live in your storefront configuration. The integrator owns this work, often with a developer. |
| Add a drop-in that is not on your storefront yet | A developer installs the package and adds the Commerce block that loads it. |
| Change how a Commerce block behaves, not just how it looks (for example, how Add to Cart works) | The behavior comes from the drop-in code, not from the block table. A developer customizes the drop-in. |
If the change is not in either table, file a ticket with the page URL, the block name (for example, product-details), and a short description of what you want that you cannot do from the author tools.
Reference
How a Commerce Storefront page is built
Section titled “How a Commerce Storefront page is built”Every Commerce Storefront page stacks three layers:
- Drop-in componentsNPM packages that provide core Commerce storefront features such as cart, checkout, product details, and account flows. — Adobe-shipped UI for Commerce features such as Product Details, Cart, Checkout, and Account. A drop-in powers the interactive Commerce parts of a page (gallery, price, cart) and loads live catalog data from Adobe Commerce. Content blocks handle other page sections, such as marketing copy or images.
- Commerce blockJavaScript blocks that integrate drop-in components into Edge Delivery Services pages to power storefront commerce experiences. — A Block tableA table in a document that begins with a block name row, followed by configuration rows. Edge Delivery uses the name row to map the table to a storefront block implementation. in your document with the block name (for example,
product-detailsorcommerce-cart) and any settings that block needs. See Block table structure for the table shape. - Page — The document that holds your Commerce blocks and any content blocks (marketing copy, images, breadcrumbs, Product Recommendations).
Most Commerce blocks live on a page you author yourself, such as your cart or sign-in page. The product page (PDP) is the exception. One document at /products/default is the template layout for every product URL, so a change there updates all product pages at once. Names, prices, and images still come from your catalog, not from that document. See Product Details for how this template works.
Roles at a glance
Section titled “Roles at a glance”- Author — Edits pages in Document Authoring or the Universal Editor. Owns shopper-facing copy, block settings, placeholders sheets, section and page metadata, publishing, and scheduling.
- Integrator — Connects the storefront to Adobe Commerce. Edits storefront configuration, store view headers, and similar settings, often with a developer when code is required.
- Developer — Owns code in your storefront repository: drop-in customization, CSS, shared style settings, new drop-ins, and analytics integrations.
On a small team, one person may cover two roles. Name the role you need on a ticket so the request reaches the right person faster.
For developer-facing vocabulary (containers, slots, events), see Introduction to drop-in components.