Inside the Studio: What GrapesJS Does and Doesn't Let You Customize
The email app's Studio is a real drag-and-drop editor built on GrapesJS — here's honestly what's customizable through the interface and what requires editing the underlying template catalog.
The Studio is where you actually build and edit email templates — a drag-and-drop editor rather than a code box. It's worth understanding what it's built on and where its real limits are, so you're not surprised by what's easy to change and what isn't.
What the Studio is built on
The Studio runs on GrapesJS, using its newsletter preset as a base, with the platform's own merge-tags plugin layered in for personalization fields. But the interface you actually see isn't GrapesJS's default panel chrome — the app replaces that with its own React-built panels, which read from and drive GrapesJS's underlying editor modules rather than using GrapesJS's stock UI. In practice this means the Studio looks and behaves like the rest of the platform, not like an embedded third-party tool with its own visual language.
Two entry points bring you into the Studio: opening a saved template your workspace has already built, or opening one of the built-in starter templates from the gallery. They're deliberately kept separate — a saved template and a starter template live in different places, so the app doesn't have to guess which store an id belongs to.
What you can customize directly
Inside the editor, you're working block by block — dragging in a header, a hero section, a feature grid, text, a signature, a footer, and rearranging or editing each one. Text content, button labels, images, and each block's own configurable options (like a hero's style variant, or which features appear in a feature grid) are all editable through the interface, with no need to touch code.
Images go through the Studio's asset picker, which is tied to the platform's shared media library rather than a Studio-only upload — an image you upload here is available to pick from in other apps that share the same asset library too, and vice versa.
What requires editing the underlying catalog
What you generally can't do from inside the Studio is invent a new kind of block. Blocks are a fixed set of types the catalog knows how to render — header, hero, features, text, and the rest — and adding a genuinely new block kind is a code change to the template catalog's renderer, not something available as a Studio option. If you need a layout element that doesn't correspond to any existing block type, the honest answer is that it's a development request, not a Studio customization.
Similarly, the visual "chrome" around the editor — panel layout, the overall styling of GrapesJS's own UI — isn't something a template author touches; it's shared configuration behind the scenes, not a per-template setting.
Working within those limits well
None of this is a serious constraint for the vast majority of what a template needs to do — swap copy, rearrange existing block types, change images, adjust a button's style variant. Where it becomes a real constraint is if you're trying to force a genuinely novel layout onto a system built around a fixed block vocabulary. In that case, the more productive path is picking the closest existing block structure and working within it, rather than fighting the editor toward something it wasn't built to represent.