Modules and elements
Emails are built from modules (sections) containing rows, columns and elements. How they're addressed, and why ids come in pairs.
A Stensul email is a stack of modules: a header, an opening section, a two-column feature block, a footer. Admins design modules in Stensul Studio, publish them, and add them to libraries. Marketers, and assistants, assemble emails from them.
email
└── module (a section, e.g. "the opening section")
└── row
└── column
└── element: text | button | image | divider | custom | …What an assistant can change
| Element | Editable through the MCP |
|---|---|
| Text | Copy, links, headings and lists, within the module’s rules |
| Button | Label, destination URL, per-link tracking |
| Image | Source (upload or gallery), alt text, destination link |
| Divider | Style and visibility only, where allowed |
| Custom element | Named variables only. Their markup is never returned and never writable |
Any element with a visibility field |
Show or hide it |
Addressing: always a pair
In a read (stensul-read-email, view plan), every element carries its own module id. Elements of the same type in different modules can share a numeric id, so updates always name the module id and the element id. When building from a template, stensul-build-email uses positions instead, so there are no fresh ids to juggle.
Removing things
- Hide an element that has a
visibilityfield. Nothing is lost. - Delete a module with
stensul-delete-email-modulewhen a whole section should go. - An element with no
visibilityfield can only go by deleting its module. If the module holds other content, the tool lists what would be lost and waits for the person to agree.
When admins update a module
Admins can publish module updates as mandatory or optional. A draft with an outdated mandatory module can’t be completed until it’s updated, and a draft that uses a module an admin removed from the library can’t be completed until that module is swapped out. Your assistant’s draft follows the same rules as any other.