By David,
Signature projects die at one of two extremes. Extreme one: a single company-wide template, which lasts until sales needs a booking link, legal needs a longer footer, and the CEO wants two lines only - at which point "one template" fragments into tolerated hand-edits. Extreme two: a template per team (or worse, per person), which is unmaintainable by month three and un-auditable forever.
The working model sits between the extremes and has been standard in configuration management for decades: scoped assignment with deterministic precedence. It's how Atlas Ink assigns signatures, and this article is the design guide - how to use each scope, and how precedence keeps the whole thing decidable.
The three scopes, and what each is for
Tenant is the default - the signature everyone gets unless something more specific says otherwise. It should cover the overwhelming majority of the org: brand block, token-driven identity (name, title, department, phone hydrated from Entra ID), standard footer. If your tenant default covers less than ~80% of people, your variants are doing work the default should do.
Group is for populations whose signature block genuinely differs - not cosmetically, structurally: sales carries the booking link, legal carries the extended disclaimer, the German subsidiary carries different entity and registration lines. Bind variants to real Microsoft 365 groups you already govern, so membership - and therefore signature - follows the org chart automatically when people move.
User is the deliberate exception list: the executive with a minimal two-line block, the general counsel with bespoke language. Every user-scoped assignment should have a reason you could say out loud in an audit; if the list grows past a dozen, some group is hiding in it.
There's a fourth state worth naming because it's governance too: unmanaged - the user who legitimately keeps a self-maintained signature. Make it an explicit switch, not a quietly tolerated enforcement failure, and the exception is policy instead of drift.
Precedence: the rule that makes overlaps boring
Real people belong to multiple scopes at once. A sales director in the UK entity who's also on the executive-exception list matches three assignments. Something has to decide - and the something must be a rule, not a support ticket.
The rule: most specific wins. User beats group; group beats tenant. Deterministic, explainable in one sentence, and stable as membership changes.
Two design consequences follow:
Keep group variants disjoint where you can. User-over-group-over-tenant resolves across levels; two competing group variants at the same level (UK entity vs sales department) is a tie your design should avoid rather than adjudicate - prefer building the combined variant (UK-sales) when a population genuinely sits in both, or scope variants along a single axis (entity or function, not both) so ties can't arise.
Write the map down. The full assignment picture - default, variants, exceptions, unmanaged list - should fit on one page. If it doesn't, you've rebuilt the per-team template pile with extra steps.
Why this beats the rules-engine alternative
The stamping products solve targeting with transport-style rules engines: conditions on senders, recipients, keywords, evaluated per message. That's genuinely more expressive - it can vary a signature by recipient, which scoped assignment can't do at all (an honest reason to pick that architecture, if recipient-conditional content is a real requirement). But expressiveness has a governance price: a growing pile of ordered rules with mutually exclusive conditions, evaluated on every send, whose interactions live in the heads of whoever wrote them. Scoped precedence trades expressive power for decidability - and for the question signatures actually pose ("which signature does this person get?"), decidability is worth more. The answer never depends on rule order, message content, or the time of day: look up the most specific assignment, done.
Governance in practice: the lifecycle
- A department asks for a variant. Gate it with one question: is the block different, or just the data? Different data (names, titles, numbers) is what tokens are for - no variant needed. A structurally different block earns a group assignment.
- Someone moves teams. Group membership changes in Entra; the next push re-resolves their scope; the right variant applies. Nobody touches signature config - that's the payoff of binding variants to real groups.
- The rebrand lands. Update the tenant default and each variant once; push; the per-user status view confirms coverage. Revision history means the typo ships back out of production in one rollback, not a second project.
- The audit asks why. "Why does this person have this signature?" has a one-line answer: here's the assignment at the most specific scope, here's when it changed, here's who changed it.
Scopes, one precedence rule, a visible exception list, and tokens doing the per-person work - that's the whole governance model, and it's boring in the way infrastructure should be. Atlas Ink ships it as the assignment system, so the interesting decisions - what your scopes are - stay yours.