The HTML editor

The HTML editor edits a template’s markup directly. It is the right tool when you need exact control, most often when recreating an existing signature so that a migration is invisible to recipients.

It is a code editor built on CodeMirror, not a rich-text surface. That is deliberate. Conditional sections and Outlook-safe nested-table markup are exactly the things generic rich-text editors mangle. Visual authoring belongs in the designer, whose documents compile to that markup for you.

Editing needs a desktop browser and a role with access to templates: Admin or Editor, a managing partner’s Owner, Admin or Technician, or a custom role given templates.

1. Open Templates in the portal sidebar.
2. Choose the template’s name, or Edit at the end of its row.

A template built in the designer has Design there instead, and opens in the designer. If one is opened here anyway, its compiled markup is shown read-only.

Placeholder autocomplete

Typing {{ offers the placeholder list. Typing {{# offers the same list as conditional section openers.

1. Put the cursor in the HTML where the placeholder should go.
2. Type {{ and choose the placeholder from the list, or type {{# and choose a field to open a conditional section on it.

The Placeholders panel below the editor lists the same fields as chips; choosing one inserts it at the cursor.

The list comes from the API rather than being hard-coded in the editor, so it cannot drift from what the renderer actually knows how to resolve. If a placeholder appears in the picker, it renders.

That includes any profile fields your organisation has defined, which appear as {{custom.<key>}} under a “User profile” heading after the directory groups. Each is listed a second time as {{sender.custom.<key>}}, for the answer given by whoever pressed Send rather than the mailbox’s own.

See placeholders for the full set and what each one maps to.

Writing for Outlook

Outlook’s HTML support is closer to a mid-1990s browser than a modern one. A few habits carry most of the weight:

Lay out with nested tables rather than flexbox or grid. Use <table>, <tr> and <td> with explicit widths.

Put styles inline on elements. A <style> block is unreliable, and external stylesheets do not survive at all.

Use pixel values for widths and font sizes rather than relative units.

Reference images as cid: and let the add-in attach them inline. See images.

Set a background colour with bgcolor on any strip that carries light text. Clients built on Outlook on the web recolour text and backgrounds together in dark mode but never touch images, so light text sitting on a picture rather than on a colour disappears there. The designer badges this risk automatically and the HTML editor does not, so it is worth checking yourself. See dark mode.

The Outlook constraints page covers the hard limits, including the 30,000 character ceiling and the lack of SVG support.

Conditional sections

Wrap anything optional so it disappears rather than leaving a stray separator:

{{#jobTitle}}{{jobTitle}}{{#department}} · {{department}}{{/department}}{{/jobTitle}}

Sections nest. Values are HTML-escaped when they are substituted. Any placeholder that is left unresolved is stripped, so a literal {{jobTitle}} can never reach a recipient.

A section left open, closed with a marker that does not repeat the opening one exactly, closed without ever being opened, or written as a rule Sigil cannot read is refused when you save a draft, publish or schedule, and the message names the marker. The preview still renders it, with the stray marker removed, so check the message rather than the preview. Without that check the stray marker would be stripped when the signature renders, and whatever it was meant to wrap would go missing with no explanation.

The either-of form described under placeholders, {{#a|b}}, is accepted, and so are & for “and”, ! for “is empty” and brackets, which are the HTML side of grouped conditions. The marker syntax covers the whole form. Typing {{# then an operator continues to offer the field list, so a longer rule can be completed rather than typed out.

Preview and diff

Preview renders the template with sample data, which is the fastest way to check that a conditional section collapses the way you intended. The two address boxes above it swap the sample data for a real mailbox, and render as if a chosen colleague had sent from it. See previewing and sending on behalf of a mailbox.

Before you publish, the editor shows a line diff between what you have written and the live version. That is worth reading every time; it catches the edit you did not mean to make far more reliably than re-reading the whole template.

1. Choose Diff in the editor’s toolbar.
2. Read the Changes vs the live version card that appears above the editor.
3. Choose Diff again to hide it.

If nothing has changed, a message says the editor matches the live version. A template of more than 800 lines is not diffed, and the editor says “Too large to diff here.” instead.

The diff is the one thing this editor has that the designer does not. Everything else about getting a body live, drafts, review, scheduling and staged publishing, works the same way in both. A diff of a block document would say nothing useful, which is why the designer does without it rather than approximating one.

Drafts

Each template holds one unpublished working copy. You can save, close the portal, and come back to it without anything reaching users. See drafts and publishing.

How it loads

The editor is part of the portal’s own build rather than fetched from a content delivery network. The portal downloads it the first time you open an HTML template, after the template, its preview and the publish controls have appeared, so those are usable a moment before the editor is. A template built in the designer never downloads it at all.

Because it is a separate download from the portal, a connection that drops at that moment can leave the editor area empty while the rest of the page works. Reloading the page fetches it again.

An earlier version of the portal did pull the editor from a CDN and kept a plain text area as a fallback for when that failed. Neither the CDN fetch nor the fallback exists any more.

Desktop only

Editing markup on a phone is not a real workflow, so the editor is blocked below 768px rather than offered in a form nobody could use.