Email templates
Your AP team writes the same replies all day: "your invoice will pay Tuesday". Your shipping desk does too: "your order ships Friday". Your support team: "we received your request, here is the ticket number". Each one carries different specifics for a different vendor, customer, or order, but the shape is the same.
Email templates capture that shape once. When inbound mail hits a mailbox bound to one of your Apps, the agent picks the right template by name and fills in the specifics from the work item. The sender gets a fast answer in your voice. Your team gets out of the repetitive-reply business.
Audience: builders
Templates live on the Project; the wiring lives on the App. Author here. When you want a mailbox to trigger an App and reply through one of these templates, see Bound email.
Find the Email templates section
Open your Project. Click the Context tab. Pick the Email templates section. The list shows every template in the Project: name, what it sends, placeholders, mailbox actions, status, and last edited.
Each template is a file at email_templates/<slug>.md in the Project volume. The path is intentional. Agents can author into email_templates/ directly during a conversation; system paths under .blockparty/ are off limits.
Create a template
Click New template
The button is in the section head, top right. A naming panel slides in.
Pick a slug
The slug becomes the filename: email_templates/<slug>.md. Lowercase letters, numbers, underscores, and dashes are allowed. Up to 64 characters.
Click Create and open editor
The workbench opens full screen as a dialog overlay. Use the back arrow in the top bar to return to the list.
Name for the situation, not the order. Templates are referenced by name from chat and runbooks. vendor_invoice_status_query and remit_confirmation survive a year of edits. template1 and new_template will not.
The workbench
Three columns inside the dialog body.
- Left rail. A sample inbound payload and a Placeholders card. Click any
inbound.*row to drop{{ inbound.sender_name }}(or similar) at the cursor. Declarevalues.*keys you want the agent to fill in. - Middle column. A Body tab with a code editor (jinja2 syntax highlight, line numbers). The Settings tab holds subject, description, and mailbox actions. The body editor and settings persist independently in the draft.
- Right column. The preview card.
The action cluster in the top bar shows your save state: Saved when clean, Unsaved when dirty. Save commits the draft to the volume. Delete removes the file.
Preview against a sample inbound
Preview is an explicit action. Click Preview in the top bar to render the in-flight draft against the sample inbound payload. The first open auto-fires once so the right column lands populated. After that, run Preview when you want to check your work.
The preview pane shows the subject, body, and the mailbox actions that would fire on send.
If something is wrong, the preview returns a structured error:
- Undefined variable. A
{{ values.X }}reference has no declared key. Add the key in the Placeholders card or guard it with a default. - Template settings are invalid. Frontmatter in the Settings tab failed to parse.
- Template renders empty. The body is blank after rendering.
- Render failed. Anything else from the renderer.
The error card calls out the offending variable by name when it can, and offers a fix to declare it or guard the reference.
Mailbox actions
Open the Settings tab to set what your agent does to the inbound email when this reply sends: mark read, add Outlook categories, add Gmail labels. Provider-irrelevant fields are dropped at dispatch.
Reference the template by name
Once saved, the template is reachable by slug. A runbook picks a template by name and passes the placeholder values it wants filled in. The agent renders the template, the platform sends from the bound mailbox, and the reply threads into the original message.
For the full inbound-to-reply wiring through an App, see Bound email.