Planning a rollout
The technical work in deploying Sigil is small. The scheduling around it is what tends to catch people out, mostly because add-in propagation is measured in hours and rarely finishes when you would like it to.
This is a plan that works for organisations of a few hundred to a few thousand mailboxes.
Before you start
Section titled “Before you start”Two facts shape the whole schedule.
Add-in propagation takes 6 to 72 hours after you deploy through Integrated apps. Nothing you do makes it faster, and treating a missing add-in as a fault inside that window wastes time.
Any later change to the manifest requires admin consent again, and users are blocked from the add-in until it is granted. Template changes, image changes and add-in code changes do not touch the manifest, so day-to-day work is unaffected. Getting the manifest right before you go tenant-wide is worth the effort.
Phase 1: connect and design
Section titled “Phase 1: connect and design”Grant admin consent and sign in to the portal. Nothing is deployed to users yet, and nothing is charged.
Build the signature you actually want. If you are migrating from another product, recreate the existing design so the change is invisible to recipients. Use the designer if you want a visual surface, or the HTML editor if you need exact control.
Run attribute coverage before you commit to a
design. It shows which directory attributes are actually populated across your
organisation. Designing a signature around department only to find a third of
the directory has none is an avoidable problem, and it is much cheaper to find
now than after rollout.
Fix the directory gaps you find, or design around them with conditional sections.
Some things the audit cannot help with, because the directory has no field for them at all. Pronouns, a personal booking link, the days somebody works. Profile fields put those in the hands of the people they describe, which is worth deciding on now rather than after everyone has seen their signature for the first time.
If the add-in is going to reach anybody before the template is ready, pause delivery first. Paused, mailboxes receive nothing while everything in the portal carries on working, so you can deploy and test the add-in without anyone getting a half-finished signature. See pausing delivery.
Phase 2: pilot
Section titled “Phase 2: pilot”Deploy the manifest through Integrated apps, targeting a small group. Ten to twenty people from more than one department is usually enough, and picking people across Windows, Mac, web and mobile gives better coverage than picking a whole team on one platform.
Wait out the propagation window. Then check Activity: you are looking for signature requests arriving, apply outcomes succeeding, and nobody stuck in the never-applied list.
Ask the pilot group to check replies and forwards as well as new messages, and to send at least one message from a shared mailbox or a Microsoft 365 Group if they use one.
Phase 3: refine
Section titled “Phase 3: refine”The pilot usually surfaces two kinds of change.
Design issues, such as a logo that is too large in Outlook on Windows or an address block that collapses awkwardly when someone has no office location. These are template edits and land within seconds.
Targeting issues, such as one department needing different contact details or a subsidiary needing its own branding. That is what assignment rules are for. Rules changes land on the next message anybody composes.
Add a compliance footer at this stage if legal needs one. It applies below every signature at render time, so it does not need to be worked into any template.
Phase 4: tenant-wide
Section titled “Phase 4: tenant-wide”Widen the Integrated apps assignment to the whole organisation, or to the groups you intend to cover. Allow the propagation window again.
Watch the never-applied list in Activity over the following week. It cross-references the directory, so it surfaces mailboxes that have never had a signature applied rather than just showing you the ones that have.
Expect a small tail. The most common cause is the first-run silent sign-in failing, which resolves when the person opens the “My signature” pane once on a desktop client. Consent is per user rather than per device, so one desktop sign-in fixes their mobile too.
Phase 5: hand over
Section titled “Phase 5: hand over”Once the rollout is stable, decide who owns what:
| Area | Usual owner | Portal role |
|---|---|---|
| Templates, images, versions | IT or internal comms | Editor |
| Campaign banners and link analytics | Marketing | Marketing |
| The legal disclaimer footer | Legal | Compliance |
| Checking that signatures are landing | Service desk | Viewer |
| The subscription and who has access | Finance or the account owner | Billing |
| Assignment rules, and everything above | IT | Admin |
Invite them under users and roles. Each role is narrow on purpose: Marketing reaches banners and link clicks only, Compliance reaches the footer, Viewer reads and changes nothing.
Assignment rules are the one thing only an Admin can change, because a rule decides who receives which signature and so reaches the whole organisation.
Add a card in Billing before the trial ends. With no card on file the subscription cancels at trial end, and once the trial ends without an active subscription signatures stop being served.
A note on running two products at once
Section titled “A note on running two products at once”If you are migrating from a server-side product that stamps signatures in mail flow, run one or the other. Sigil applies the signature in the compose window, so a server-side stamp on top of it produces two signatures on every message.
Turn the old product off for the pilot group at the same time as you deploy Sigil to them, rather than sequencing the two.
If the two cannot be switched over in the same moment, deploy the add-in with delivery paused and resume at the instant the old product stops. That turns a cutover that depends on propagation timing, which you do not control, into one that depends on a button, which you do.