The drag-and-drop designer

The designer is a visual, block-based editor for building signatures. You assemble a design from blocks; when you publish, the service validates the design and compiles it to Outlook-safe nested-table HTML.

That compiled HTML is what gets stored, versioned, rendered and cached. Nothing downstream knows design documents exist, which means a designed template behaves identically to a hand-written one everywhere else in the product.

Open it from the template library in the portal. The designer’s address on its own, without a template chosen, shows only “No template selected”.

Editing needs the templates capability, which the Admin and Editor roles hold and a custom role can be given, and a desktop browser.

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

A template authored in the HTML editor has Edit in place of Design, because it opens in the HTML editor instead. The arrow at the left of the designer’s top bar takes you back to the library.

Blocks

A design is a tree of blocks on a canvas.

Block	What it does
Columns	A multi-column layout row. Compiles to a nested table
Text	A run of text, with placeholders and inline formatting
Image	A logo, headshot or badge, attached inline
Button	A styled call-to-action link
Social icons	A row of linked icons, drawn from a built-in set or from your own uploads
QR code	A scannable link, or the sender’s own contact card
Photo	The sender’s own Microsoft 365 profile photo
Divider	A horizontal rule
Spacer	Vertical space
HTML	An escape hatch for markup the blocks do not cover

Rows are how you get side-by-side layouts, such as a logo on the left and contact details on the right. Columns can be sized as a percentage of the row or at a fixed pixel width, and columns you do not size share what is left.

The QR code and Photo blocks behave differently from the rest, because the image each one produces depends on who is sending. See per-user images.

Adding a block

1. Drag a tile from the Blocks rail on the left onto the canvas.
2. Drop it in the gap where it should sit, between two blocks or inside a column.

The new block is selected as it lands, so its settings are already open in the inspector on the right. Columns cannot be dropped inside a column. Every block has a handle with Duplicate and Delete on it; a selected block also goes with the Delete key.

Social icons

A social icons block ships with 27 built-in marks, so a row of logos needs no upload and no hunting for artwork.

Group	Marks
Social networks	LinkedIn, X, Facebook, Instagram, YouTube, TikTok, WhatsApp, Threads, Bluesky, Mastodon, Pinterest, Snapchat, Reddit, Discord, Telegram, Twitch, Vimeo, GitHub, Behance, Dribbble, Medium, Substack, Spotify, Xing
Contact	Website, Email, Phone

Every mark is drawn on the same grid, which is what makes a row of them line up. Sourcing twenty logos from the web and cropping them yourself rarely does.

Choosing a mark fills in its label and the start of its link for you, so a LinkedIn icon arrives already pointing at the right kind of address. Both are yours to change, and the link can carry placeholders so each person’s icon points at their own profile.

Each icon is either a built-in mark or an image you uploaded, never both. Anything the set does not cover is still an upload, exactly as before.

Ordering the icons

Icons render in the order they are listed, and each one has a pair of buttons for moving it earlier or later in the row. They are buttons rather than a drag, because the list lives in the inspector panel rather than on the canvas.

Icons that appear only for some people

Each icon carries its own Show when rules, the same as any block, so a row can hold one icon per attribute and show each person only the ones they have. Point the link at a placeholder and the icon reaches that person’s own profile.

When every icon in the row is conditional and nobody in a particular message has any of them, the whole row disappears rather than leaving its padding, background and border wrapped around nothing. You do not have to set that up. Sigil works out the condition for the row from the conditions on the icons inside it.

An icon with no condition means the row always has something to show, so the row is never hidden. Text blocks collapse the same way and for the same reason. See blocks that empty themselves.

To give one icon a condition:

1. Select the social icons block on the canvas.
2. In the inspector, find the icon under Social icons. They are numbered Icon 1, Icon 2 and so on, in the order they render.
3. Under its Show when, choose Add rules.
4. In the Show when dialog, choose Choose a rule and pick the field the icon depends on.
5. Choose Done.

Several rules can be chosen. They are joined with “and” to begin with, so every one of them has to hold, and choosing the “and” makes it “or”.

Styling the row

The look is set once for the whole block rather than per icon, because a row where one logo sits on a circle and the next is a bare glyph reads as a mistake.

Setting	Options
Icon style	Just the mark, on a circle, on a rounded square, or on a square
Colour	Each network’s own brand colour, or one colour for the whole row
Mark colour	The mark knocked out of the backdrop, where there is one. White by default

Size and the gap between icons are set on the block as usual. Nothing here fixes the artwork at a size or a colour beforehand, so changing any of it costs nothing.

What the marks cost you

Built-in marks are drawn when a message is signed rather than stored, so they take no space in your image library and there is nothing to clean up when you change the row.

They are attached to the message like any other signature image, at roughly 2.5KB for a typical icon, which is the same trade every inline image makes. See images.

The marks are the trademarks of the networks they belong to. They are there so a signature can link to a profile on that network, which is what those brands’ guidelines allow, and not for any other use.

Block styling

Every block, and every column, can carry a background colour and a border.

The border is uniform on all four sides, with a width, a style of solid, dashed or dotted, and a colour. There is deliberately no corner radius and no per-side control. Classic Outlook renders a rounded table cell as square anyway, and per-side borders produce more misaligned signatures than good ones.

A background plus a border on a column is what a card or a coloured sidebar stripe is made of. Backgrounds default to transparent, which is the right default for email.

To style a block or a column:

1. Select it on the stage.
2. In the inspector, open Background & border.
3. Pick a background colour. The clear button next to it removes the background again.
4. Turn the border on and set its Width, Style and colour.

Buttons are the exception. A button’s background colour is the button’s own fill rather than the cell behind it, because a button already is a coloured box.

Vertical alignment

Blocks and columns can both be aligned vertically, but they answer different questions and it is easy to reach for the wrong one.

Column alignment is the one you usually want. When one column is taller than another, setting the shorter column’s vertical alignment to middle is what puts contact details level with the photo beside them.

Block alignment only does something when the block has room to move within its own cell, which means setting a minimum height as well. A block normally sits in a cell exactly as tall as its content, so alignment alone has nothing to work with. The designer still lets you pick a value, and shows a note under the control saying vertical alignment needs a minimum height to work within.

Text formatting

Selecting a text block brings up a formatting toolbar inside the block itself, so the controls sit where you are already looking rather than at the top of the stage. It covers bold, italic, underline, colour, links and inserting a field.

Adding a link opens a dialog rather than a browser prompt, and the dialog says so when nothing is selected. Linking needs selected text to attach itself to, so with only a cursor there is nothing to link and the old prompt looked broken rather than refused.

Text blocks can be sized in points as well as pixels. Points are what people authoring in Word and Outlook think in; pixels are what the web thinks in. Fractional sizes are accepted, which matters when you are matching an existing signature.

Canvas settings

The canvas holds the defaults every block inherits. To change them:

1. Press Escape, or click an empty part of the stage, so that no block is selected.
2. The inspector shows Signature settings. Width and Font stack are under Canvas, Text and Links under Colours, and machine-readable contact details under Contact details.

What each one controls:

The overall width in pixels, which is the width of the outer table.

The font family, the default text colour, and the default link colour. A block or an individual run of text can override any of them.

The canvas background is always transparent. The designer has no setting for it, and transparent is the right default for email, because a signature sits on whatever background the recipient’s client uses.

Machine-readable contact details, which is off by default. Switching it on labels the signature with schema.org Person markup, so a client or a crawler can read it as a contact rather than as text. Nothing moves and nothing is added to what the recipient sees, because microdata is attributes on the markup that is already there. See the contact card link.

Placeholders in the designer

Text blocks accept the same placeholders as a hand-written template. Insert them from the field menu rather than typing them, so the token always matches something that actually renders.

1. Select the text block and put the cursor where the field should go.
2. Choose Insert field on the block’s toolbar.
3. Pick the Mailbox or Sender segment.
4. Type in the search box to narrow the list, then choose a row.

The field lands at the cursor as a chip. Choosing Insert field without first putting the cursor in the block appends the chip at the end.

The field menu is segmented, grouped and filterable. Each row shows the field’s label with its {{token}} underneath, so a long field name never competes with its token for width. Typing in the filter narrows the list; choosing a row inserts that field at the cursor.

The designer fetches its field list from the API, which means the picker cannot drift from what the renderer knows how to resolve. Any profile fields your organisation has defined arrive that way too, under a “User profile” heading after the directory groups, and each one also appears in the Sender segment described below as the answer given by whoever pressed Send.

The menu has two segments, Mailbox and Sender. Mailbox is the account the message goes out from, and Sender is the person composing. Almost every sender field shadows a mailbox one, so a single flat list showed each attribute twice and the one you wanted was always the other. The segment asks the question that separates them: whose value do you mean. Within the Sender segment the rows are grouped the same way the mailbox rows are, by the field they shadow.

Sender fields look identical to the mailbox’s own on an ordinary send, so the preview pane’s second address box exists to show you the case where they differ. See previewing, the sender placeholders, and lines that appear only on a shared mailbox send for hiding content behind that case rather than printing it.

Placeholders in links

Every link box in the designer accepts placeholders too, and each one carries the same field picker as the text toolbar. That covers the link dialog and the link on a field chip, an image, a button, a social icon, a QR code and a photo block.

This is what tel:{{mobilePhone}}, mailto:{{mail}} and a per-person booking link such as {{custom.booking}} are made of. The token is inserted where the cursor is rather than appended, so a prefix such as tel: stays in front of the field. Clicking the picker without putting the cursor in the box appends instead, which is what somebody who goes straight to the menu is asking for.

The boxes have always accepted placeholders. Until now the label said so and left you to remember the field names, which is exactly the knowledge the picker exists to remove.

Conditional blocks

Any block can be given Show when rules, under Visibility in its settings. The block is emitted wrapped in a conditional section and disappears entirely for people where that field is empty.

This is how you avoid the classic problems: a phone row that leaves a dangling label for people with no phone number, or an address block that collapses to a line of commas.

1. Select the block on the canvas.
2. In the inspector, open Visibility. Show when reads “Always” while the block has no rule.
3. Choose Add rules.
4. In the Show when dialog, choose Choose a rule, pick the Mailbox or Sender segment, and choose the field the block depends on.
5. Choose Done.

The rule reads back in the inspector as a sentence, such as “Mobile has a value”, and the block carries an “if” badge on the canvas. Choose Edit rules to change it, or remove the rule with the cross beside it in the dialog. The dialog can also combine several rules with “and”, “or” and “not”, which is covered under and, or and not in one rule.

Six derived conditions help here. anyPhone is true when the person has a business or mobile number (a fax number does not count), anyAddress when they have a street address, a city or a country, and hasPhoto when their mailbox has a Microsoft 365 profile photo. Attaching a whole row to one of those lets the entire row disappear rather than each field inside it. The fourth is sent on behalf of the mailbox, which is about who is sending rather than about what the directory holds. The last two are a pair: “sent from a group mailbox” is true when the mailbox is a Microsoft 365 Group or distribution list, and “not sent from a group mailbox” is its opposite, for the line that assumes a person, such as a “Chat with me in Teams” link. They became a pair when a rule could not be turned round. Any rule can be now, with not, so the second of the pair is a convenience rather than the only way.

The Sender tab of the menu has its own versions of the first two, listed under Conditions at the top as “Any of the sender’s phone numbers has a value” and “Any of the sender’s address lines has a value”. On the canvas badge they read Sender any phone and Sender any address. They test the phones and address of whoever pressed Send, so a row of the sender’s phone numbers can hang on the sender’s phones rather than on the mailbox’s.

None of these can be inserted, because none of them prints anything. They appear only when you are choosing a condition, and they head the list there rather than sitting at the bottom of it, since a whole row is more often hung on one of them than on a single attribute.

A Photo block carries the hasPhoto condition automatically, so you do not need to set it yourself.

Conditions on a single field

Selecting a field chip inside a text block gives that chip its own visibility rules, separate from the block it sits in. So one line can carry a job title, a department and a qualification and print only the parts a given person actually has.

1. Select the chip inside the text block.
2. In the inspector, open Visibility.
3. Under Show when, choose Add rules, or Edit rules if the chip already has some.
4. Choose each field the chip depends on. The field menu stays open until you close it, so several can be picked in one go.
5. Choose Done.

Several rules are joined with “and” to begin with, so every one of them has to hold. Choose the “and” to make it “or”.

A block takes as many rules as a chip does. A row that needs two conditions can carry both itself, rather than being nested inside another row to get the second.

Conditions on labels and separators

Plain text can carry a rule of its own too. Highlight it and press the eye button on the text toolbar, whose tooltip reads “Show the highlighted text only when a rule holds”, then choose the fields it depends on. Leaving the dialog with no rules shows the text always. That is how a label such as “T: “ or a separator such as “ | “ goes away with the value it belongs to, rather than being left behind with nothing after it.

1. Highlight the text inside the block.
2. Choose the eye button on the text toolbar. Its tooltip reads “Show the highlighted text only when a rule holds”.
3. In the Show when dialog, choose Choose a rule and pick each field the text depends on.
4. Choose Done.

Choosing the button with nothing highlighted opens a message saying so rather than a dialog.

Text with a rule has a dotted underline on the canvas. Selecting the text block lists every such part under Parts of this text in its Visibility settings, each with its rule, so you can change or remove one without hunting for it.

The starter design uses these. Its phone labels, the separator between the two phone numbers and the comma in the address each show only when the field they belong to has a value.

And, or and not in one rule

The everyday case is one rule, or several that all have to hold. A customer running several shared mailboxes asked for the other case: show this when either of two things is true. That is what grouped conditions are. They are available to every organisation, and a design built before them renders exactly as it did.

Every Show when control in the inspector reads as a sentence with an Edit rules button beside it. The sentence is the rule in words, such as “Mobile has a value or Email has a value, and the message is not sent on behalf of the mailbox”. Blocks, field chips, social icons and highlighted text all use the one dialog.

1. Select the block, chip or icon, or highlight the text and choose the eye button on the text toolbar.
2. Open Visibility and choose Edit rules, or Add rules where there are none yet.
3. Choose a rule from the field menu, the same menu you insert fields from.
4. Add each further rule with Add rule.
5. Choose the “and” between two rules to switch the whole list to “or”, and choose it again to switch back.
6. Choose not on a rule to turn it round, so “Mobile has a value” becomes “Mobile is empty”.
7. Choose Add a group for a bracket with a connective of its own.
8. Choose Done.

The word between two rules is the control rather than a label. Every list is all ands or all ors, so there is one word to read and one to click, and a rule reading “a and b or c” cannot arise to be misread.

A group is a bracket: a rule down its left, its contents indented, and its own “all of” or “any of” cap. One level of nesting is offered in the dialog, which is enough for “either of these two, and that one”. The design document allows three, and a marker written by hand in the HTML editor has no depth limit at all.

The dialog holds the rule while you shape it and writes it once when you choose Done, so an edit is one step to undo rather than one per click. Closing it without choosing Done leaves the rule as it was.

The canvas badge summarises what it can. A rule naming more than three fields elides, reading “if Mobile or 3 more” rather than running off the block.

On the HTML side the same rule is written inside the section marker. See conditional sections.

Labels on a shared mailbox’s signature

Those rules test the mailbox’s own fields unless they name a Sender field. That matters when you move a chip to its Sender twin, for example from Business phone to Sender business phone. The chip now prints the delegate’s number, but the “T: “ beside it still hangs on the mailbox’s business phone. From a generic shared mailbox with no phone of its own, the number prints and its label vanishes.

The chip’s settings warn when that is the case, counting the rules and links in the block that still use the other form of the field, and offer to switch them to match. Switching also moves a tel: link built from the old field, and the block’s own Any phone or Any address condition where it has one.

Check the result against a real mailbox rather than the sample person. The sample has every field filled in, so a failing rule can never show there. Put a sparse shared mailbox in the preview’s first address box and a colleague in “Sent by”.

Lines that appear only on a shared mailbox send

A signature can carry a line that shows up only when somebody is sending from a shared or delegated mailbox, so sales@ reads “Jane Doe on behalf of Sales” while the same design from Jane’s own mailbox does not. The condition is called “Sent on behalf of the mailbox”, and it is set exactly like any other visibility condition.

What you want to hide	Where the setting is
A whole block, including a row and everything in it	Select the block, open Visibility, and set Show when
One field chip inside a line of text	Select the chip, open Visibility, and add it as a rule
A label, separator or other plain text	Highlight it and press the eye button on the text toolbar
A single social icon	Select the social block and set Show when on that icon

A block carrying a condition shows an “if Sent on behalf of the mailbox” badge on the canvas, so a line that is invisible for most people is not invisible to you while you are working.

Show when is the same field menu you insert from, in a mode where a row is picked as a rule rather than inserted. A chosen rule reads back as the sentence it is: “Mobile has a value” for a directory attribute, and “The message is sent on behalf of the mailbox” for this one. The derived conditions are worded as the fact they test rather than as a value, because none of them is a directory attribute Sigil could find empty. It works the answer out for each message.

Condition the line on that entry rather than on one of the Sender fields. The Sender fields fall back to the mailbox’s own values when nobody else is sending, so they almost always have a value, and a chip conditioned on “Sender first name” would show on every send. See sending on behalf of a mailbox.

A text block whose chips are all conditional on it collapses on its own, so you do not have to set the same condition on the block as well. See blocks that empty themselves.

Two things are worth knowing before you build around it.

The condition can be turned round with not, in the rules dialog, to show a line only when nobody is sending on behalf of the mailbox. Usually you do not need to, because the Sender fields already read correctly both ways. When you genuinely need different content for a shared mailbox, give it its own template with an assignment rule, which matches the mailbox.

A line behind this condition disappears when the directory cannot be reached at the moment of composing. Sigil falls back to the signature the mailbox would have had anyway rather than printing a half-filled clause.

To check it, use the second address box in the designer’s live preview, labelled “Sent by”. Name the shared mailbox in the first box and a colleague in the second, and the conditional lines appear. Leaving it blank gives you the ordinary send, which is what everybody who is not a delegate will see.

Blocks that empty themselves

A block whose contents have all disappeared used to leave its own shape behind: the padding, the background, the border, and for a text block the height of a line. In a signature that reads as an unexplained gap, and it only ever showed up for the people whose directory record was sparse.

Sigil now works the condition out for you. When everything a block can print is conditional and none of it applies to a particular person, the block goes with its contents. That covers a text block whose field chips are all conditional, and a social row whose icons all are. Anything unconditional anywhere in the block means it always has something to show, so it is never hidden.

Line breaks and spacing do not count as something to show. A text block of conditional chips separated by breaks still collapses, because a block left standing for the sake of its own line breaks is exactly the blank line this removes. A block that holds nothing but line breaks is left alone: that is deliberate vertical space, and no condition of Sigil’s belongs on it.

Seeing the banner and footer

The live preview has a Banner & footer switch. Turned on, it adds whatever campaign banner and compliance footer are in force for the mailbox you are previewing as, so you see the signature as recipients will. Hovering over the switch names them. When nothing is active the preview does not change, and the hover says so. When the template has campaign banners switched off, no banner is shown and the hover says that instead. The same goes for a template with the compliance footer switched off: no footer is shown, and the hover says “The compliance footer is off for this signature, so none is shown”.

With the switch on, a Banner date field appears beside the preview’s other fields. Pick a date and the preview shows the banner that will be running on that day, so you can design against a scheduled campaign before it starts. Leave it blank for today.

1. Open the live preview and turn on Banner & footer.
2. Under Banner date, choose the day you want to see.

Three things to know about what the date does:

What moves	Only the banner. A footer has no window, so it is the same on every date
Which moment of the day	Midday UTC. A banner that starts later than that on its first day shows from the following date
Paused banners	Not shown, because the date answers what a real send would carry on that day. To see a paused banner, use Preview on the Banners view

Where two windows overlap on the chosen date, the preview shows the one that would win, by the same rule a real send follows.

Checking a design in dark mode

The live preview has a Dark mode toggle. It shows the render put through the same recolouring a client built on Outlook on the web applies, with images and borders left alone, so a strip that loses its text there loses it in a real message too.

The designer also badges any block likely to fail in dark mode, and shows the count in the footer beneath the canvas. Those badges are advice and never stop a publish, which is why they are worded differently from the ones that do.

See dark mode for what the client is doing and how to design around it.

Publishing

Publishing validates the design and compiles it. Validation errors are written to be actionable rather than technical, so a rejected publish tells you which block is wrong and why.

The compiled output carries the same {{placeholder}} and {{#section}} syntax as a hand-written template, and is subject to the same Outlook constraints, including the 30,000 character limit.

The same publishing controls as the HTML editor

Everything the HTML editor can do with a body before it goes live, the designer can do too.

Control	What it does
Save draft	Keeps the working copy without changing what anybody receives
Discard, or Discard draft once one is saved	Reverts unsaved edits, or with a draft saved, deletes it and reloads the published design
Submit for review	Puts the draft in the approvals queue
Approve and publish, Send back	The approver’s two choices on a submitted draft
Schedule	Books the publish for an instant you choose
Staged	Publishes to 10% of mailboxes first, as a staged rollout

This matters most where publish approval is switched on. A designer template only ever opens in the designer, so an editor who could not publish and had no draft to submit would have had no way forward from this screen at all. Submit for review takes the primary position for them, rather than sitting next to a Publish button the server would refuse.

The one thing the designer does not have is the line diff. A diff of a block document says nothing useful, so the review step here is reading the canvas and the preview rather than reading changed lines.

What the top bar is telling you

The state beside the template name describes what is on the canvas, which is not always what users are receiving.

State	What it means
Published, with the version number	The canvas matches the live signature
Unpublished changes	Edits that are not saved anywhere yet
Draft, saved, not published	A saved draft. Users are still on the published version
Draft, unsaved changes	A saved draft with further edits on top of it
Draft, awaiting review	Submitted, and waiting for an approver

Opening a saved draft leaves the canvas clean, so a bar that only distinguished clean from dirty would read as published while showing something nobody has ever received.

Watching a rollout from the designer

While a staged rollout is running on the template you have open, a strip sits under the top bar showing the percentage, both versions’ apply failure rates, and what the evaluator will do at its next pass. Promote now and Roll back are on the strip.

It updates as the rollout moves, so the counts change continuously even though the evaluator only takes a decision every fifteen minutes. If the designer loses its live connection to Sigil, it falls back to checking once a minute while the tab is visible.

A booked publish shows as its own strip, with the option to cancel it, and says plainly that it publishes the design captured when it was booked rather than what is on the canvas now.

Those strips are read-only status. Anything that takes input, including scheduling and sending a draft back, opens a dialog.

Ejecting to HTML

A designer template can be ejected to HTML. This converts it to a hand-authored template containing the compiled markup, and it is one-way.

There is no button for it in the portal. Opening a designer template in the HTML editor shows its compiled markup read-only, with Save draft and Publish disabled, so the design document cannot be discarded by accident. Ejecting is done through the API: publishing plain HTML to a designer template is refused unless the request says explicitly that ejecting is intended. After that, the template is edited in the HTML editor from then on.

Eject when you need something the blocks cannot express and the HTML block is not enough. HTML cannot be imported back into the designer.

Do not eject a template that uses a QR code or a Photo block. Those images are generated from the design document, and ejecting discards it. See per-user images.

When to use the designer, and when not to

The designer is the right tool when you are building a signature from scratch and want it to look right without writing markup.

The HTML editor is usually better when you are recreating an existing signature exactly, such as during a migration from another product where the goal is for recipients to notice nothing.

Desktop only

The designer is a code-adjacent surface with a lot of precise interaction, so it is desktop only. Below 768px the portal blocks it rather than offering a cramped version of it.