Customer.io Design Studio canvas editor: when to stop hand-coding your emails

In 1947 Frances Gerety, a copywriter at the Philadelphia agency N.W. Ayer, wrote four words for De Beers: "A Diamond Is Forever" (The Drum). Colleagues objected to the grammar and wanted will be forever. Gerety kept is, believing it gave the line the weight of a proverb (ADIF). The line first ran in 1948, and Advertising Age named it the top advertising slogan of the 20th century in 1999.

The asset was the copy, and the person who wrote it decided what it said. In a hand-coded email, that is often not true. The marketer writes the words, then waits for a developer to change them. Customer.io's Design Studio canvas exists to give the words back to the writer. This post sorts your emails into the ones that should move there now and the ones that should stay in code.

TL;DR: The Design Studio canvas update of 14 August 2026 was small: slash commands to add blocks, shortcuts to navigate and resize, and dragging a block by any part of it. What moves the line between canvas and code is Rules, which show, hide or repeat a component from Liquid without writing code. Build newsletters, promotions and lifecycle emails on the canvas now. Build most transactional emails there too, with a developer owning the publish step. Keep code for the component library, AMP, Transformers such as MJML, and imported HTML you will not rebuild. Custom components lock their content and styles by default, so marketers cannot break the brand by accident, though anyone with edit rights can still detach a component.

What the August update changed

The release note for 14 August 2026 lists three changes:

• Slash commands: type / in a text block to insert a component.
• Shortcuts to navigate and resize elements.
• Dragging a component from any part of it, not just its handle.

That is a quality-of-life release, not a new capability. Nothing in it lets the canvas do something it could not do the day before.

The visual editor docs, updated 5 October 2026, describe the canvas as it stands now. Your email sits on a zoomable artboard, like the Automations workflow builder. Column gutters snap to a 12-column grid. You drag grip pills to set padding per viewport. Typing {{ opens Liquid autocomplete from your sample data, and Cmd/Ctrl+F opens find and replace.

All of that makes the canvas faster for people already using it. If you read the release note looking for a reason to move your coded emails, it does not give you one. The reason is on a different docs page.

What actually moves the line: Rules

The case against building lifecycle emails visually used to be Liquid. Conditions and loops meant code, so the developer kept the email. Design Studio's Rules change that.

Click a component, open the Rules tab in the Properties menu, and add a rule. A rule does one of three things:

• Shows or hides the component on a condition, built from dropdowns with AND or OR, or written by the agent from a description.
• Loops through a list. Each item becomes its own component, so a looped paragraph that returns three items gives three paragraphs.
• Hides the component by device, on screens of 600px or narrower, or wider.

Once the email is linked to an automation, broadcast or transactional message, the dropdowns list that workflow's data, such as the triggering event. A layers icon marks which components carry rules, so the next person can see the logic without reading code.

For logic inside a sentence, you type Liquid straight into the text. The Personalization panel inserts attributes without remembering syntax, and Preview renders the email as a chosen person (Liquid in the visual editor). The Review panel validates Liquid syntax and flags a missing unsubscribe link before you send.

For most Liquid-heavy emails, that removes the reason to keep them in code.

Which emails go where

Here is where we would build each type of email in Customer.io today, based on what the docs say each editor can do.

Email	Build it on	Why
Newsletter or broadcast	Canvas	Content changes every send; global styles carry the brand
Promotion or sale	Canvas	Speed matters more than custom code
Onboarding and lifecycle	Canvas, with Rules	Conditions and loops are point-and-click
Receipt or order confirmation	Canvas with a loop rule, or a coded component	A developer owns publishing
Password reset	Canvas	Simple layout; the risk is the publish step
AMP email	Code editor	AMP lives in the code editor's AMP tab
Existing MJML library	Code editor	MJML runs as a Transformer
Imported HTML	Rebuild on canvas, or keep in code	Non-semantic tags need extra markup
Header, footer, shared blocks	Code, as custom components	Properties and slots are defined in code

The pattern: emails go on the canvas, and the building blocks behind them go in code. Hand-coding each email is the habit to stop. Hand-coding the components is the job a developer should keep.

Our complete guide to Design Studio recommends a similar hybrid, but it treated the visual editor as the place for standard layouts. With Rules, it is also the place for most personalised ones.

Newsletters and promotions: move them now

Newsletters and promotions change every send, rarely need logic beyond a first name, and are usually written by someone who does not code. Every edit routed through a developer can cost a day for a change that should take a minute.

On the canvas, the brand comes from global styles: colours, fonts and spacing assigned to headings, paragraphs, links, buttons, dividers, images and sections. Drag in a button and it already looks like your button. For a primary and secondary button or a seasonal look, brand variants give one component several saved looks. Our dark mode guide covers the colour traps.

There is a second reason to stop hand-coding promotions. Design effort is not the same as results. For Bikinilists, a database provider for the creative industry, we tested a plain-text approach against their original email. Click-through rate rose 140%, past statistical significance, and the gain held across campaigns. A team that spends two days coding a layout has less time to write and test the words.

If you want to see what good looks like before you build, browse our email design examples.

Lifecycle emails belong on the canvas

Onboarding, activation, win-back and renewal emails carry the most personalisation and change most often as you learn. They suffer most from a developer queue, and Rules cover the three kinds of logic they need:

• A block only some people see: a condition rule, such as an upgrade section for free-plan users.
• A list from the person's data: a loop rule, such as one card per unfinished setup step.
• A phrase that varies: Liquid in the text, with a fallback.

The fallback is not optional. The docs warn that emails fail to send if a recipient lacks the data the Liquid asks for, unless you add a fallback. Preview as someone with the data and as someone without it. Our Liquid anti-patterns post covers the mistakes that slip through.

Two limits are worth knowing. Event fields only appear in the Personalization panel if someone performed the trigger event in the last 30 days. A new automation may need a test event first (Liquid in the visual editor). Objects that are not the automation's trigger have limits too. References are relative to each person, and only the 10 most recently created objects of a type can render (Rules docs). That is a data-model limit. Our reading is that switching to the code editor will not help, because the same Liquid runs there.

Where we would still reach for code: logic that has to change HTML structure across several blocks, rather than show, hide or repeat one component. Build that block as a custom component and let marketers drop it in. That is our judgement from the docs, not a documented limit, so test your case in Preview first.

Transactional emails: canvas build, developer-owned publish

We expected to keep transactional emails in code. After reading the docs, we changed that. The build can move to the canvas; the release should stay with a developer.

Design Studio emails link to transactional messages, and the Personalization panel has a Transactional data type where you paste sample message_data JSON and preview with it. A loop rule on a product row lists the items in an order. A password reset is a heading, a paragraph and a button.

The risk is in how changes reach the live email, and the docs describe four behaviours that matter.

• Edits go live only when you publish. Emails and components save automatically. A linked message does not change until someone clicks Publish (publish docs).
• Publishing compiles everything unpublished. If a teammate edited a paragraph and you publish a style change, both go live.
• Changing a default style variant changes existing emails. The docs advise creating a new variant if existing content should not change (global styles). Our brand variants post covers the trap.
• Liquid errors stop the send, and the Review panel shows them in red.

None of these is a reason to hand-code a receipt. They are reasons to decide who presses Publish on transactional emails. We give that job to whoever owns the code that sends the API request, because they know when message_data changes shape. If your receipts also carry offers, our post on transactional emails with marketing upsells covers where the line sits.

What still belongs in code

Every Design Studio email has both a visual editor and a code editor on the same file (Design Studio overview). These jobs stay in code.

Custom components. A component saved from the visual editor is locked: no custom properties or slots (components docs). To give marketers choices, such as an editable headline and two background options, someone writes the component in code (coding a component).

AMP and Transformers. The code editor has HTML, Text, AMP and Transformers tabs. Transformers change the compiled source: MJML, CSS inlining, URL parameters, accessibility fixes and more.

Imported HTML you will not rebuild. Text inside <div>, <span> and <table> must be wrapped in <x-edit-text> before you can edit it on the canvas. Those tags take no styles from the Properties menu (conversion docs). Classic Layouts are not supported at all and become custom components or templates.

Locking the brand so marketers can build

Moving emails to the canvas only works if marketers cannot break the brand by accident. Design Studio handles that at the component level. If you are comparing email design tools on locked branding elements, this is how Design Studio does it.

• Locked by default. The starter component code builds a block with uneditable content and locked styles. The docs suggest this for headers and footers (coding a component).
• Set choices. Properties can limit a marketer to styles a developer defines, including global style variants.
• Set placement. allowedParents lets a component go only inside a named parent, such as social icons inside the footer.
• One source. Edit the source component and the change reaches every Design Studio email that uses it, ready to publish.

Know the limits before promising anyone a locked brand. Anyone who can edit content can detach a component, turning it into ordinary blocks for that email, or open its source file. Workspace Admins and Authors have full access to Design Studio, and Viewers can only view. A custom role with the Edit content permission is the lever for everyone in between (Review panel docs). The docs we read describe no setting that locks a component against an Author. Locking prevents accidents; roles do the rest.

Only one person can edit a Design Studio message at a time, too. Anyone else is offered Take over Editing or View Only, so agree who holds each email during a launch.

When not to move

There are honest cases for leaving an email where it is.

• It works and rarely changes. A coded password reset untouched for a year gains little from a rebuild. Move it when it next needs work.
• You have hundreds of classic emails. The converter handles only drag-and-drop emails, one at a time, on the latest Liquid renderer. For code and rich text emails, Customer.io recommends rebuilding with global styles and components. You can also paste or import HTML into the code editor (conversion docs). Our conversion guide sets the order.
• Nobody will own the components. Without a maintained library, marketers rebuild the header by hand in every email.
• Your emails come from a pipeline, not a person. Then content as code through the API is the better route.

The agent can also create or edit Design Studio emails at your request (visual editor docs). Our Design Studio AI review covers the checks AI output still needs.

A migration order that works

1. Set global styles first: colours, fonts, spacing, heading and paragraph styles.
2. Code the shared blocks as components: header, footer, product card. Lock what must not change.
3. Move the newsletter, so the team learns the canvas on the email it touches most.
4. Move lifecycle emails one automation at a time, previewing each type of person before publishing.
5. Move transactional emails last, with an agreed publisher and real message_data in Preview.
6. Leave AMP and MJML emails in code until there is a reason to touch them.

Before anything goes live, check it in the inboxes your readers use. Inbox previews give 25 free credits a month on paid plans (Review panel docs). Our inbox previews vs Litmus comparison covers when that is enough.

If you want your team trained to build on the canvas, or the component library built for them, our Customer.io and email marketing training covers both. Or send us an enquiry and tell us what you send today.

Frequently asked questions

Which Customer.io emails should stay in code?

Customer.io emails that need AMP, Transformers such as MJML, or imported HTML you will not rebuild should stay in the Design Studio code editor. Shared blocks such as headers and footers should also be written in code, as custom components with properties and slots (code editor docs).

What changed in the Design Studio canvas in August 2026?

The 14 August 2026 Design Studio update added slash commands to insert blocks, shortcuts to navigate and resize, and dragging a component by any part of it (release note). It made the canvas faster but added no new capability.

Can I use Liquid in the Design Studio visual editor without writing code?

Design Studio's visual editor handles most personalisation without code, because Rules show, hide or repeat a component from conditions built with dropdowns or written by the agent. You can also insert attributes from the Personalization panel (Rules docs).

Should transactional emails be built in Design Studio's visual editor?

Most transactional emails can be built on the Design Studio canvas, because loop rules list order items and Preview takes sample transactional data. Keep the publish step with a developer, because publishing pushes every unpublished change in the email (publish docs).

Who should publish Design Studio transactional emails?

The person who owns the code that sends the transactional API request should publish Design Studio transactional emails, because they know when message_data changes shape. Publishing also pushes teammates' unpublished edits, so one named publisher avoids surprises (publish docs).

Which email design tools let you lock branding elements?

Customer.io Design Studio lets you lock branding elements: custom components lock their content and styles by default, and developers can limit marketers to set styles and placements. Anyone with edit rights can still detach a component, so locking prevents accidents rather than replacing roles (coding a component).

Does Customer.io Design Studio support AMP emails?

Customer.io Design Studio supports AMP through the AMP tab of its code editor, not the visual canvas (code editor docs).

Can two people edit the same Design Studio email at once?

Only one person can edit a Design Studio message at a time; anyone else who opens it can take over editing or view only (Design Studio overview).

Sources

• Customer.io, Design Studio: new and improved canvas editing experience, release note, 14 August 2026.
• Customer.io, Get started with the visual editor, updated 5 October 2026.
• Customer.io, Rules: display content based on conditions.
• Customer.io, Add and preview Liquid in the visual editor.
• Customer.io, Review your email for quality and accessibility.
• Customer.io, Assign global styles to components.
• Customer.io, How to create and edit a component.
• Customer.io, Create a component from scratch.
• Customer.io, Get started with the code editor.
• Customer.io, Edit linked messages and publish changes.
• Customer.io, Convert emails to Design Studio.
• Customer.io, Welcome to Design Studio.
• The Drum, De Beers 'A diamond is forever' campaign.
• ADIF, A Diamond Is Forever: the slogan's history.
• NerveCentral, Bikinilists case study.