Roles and capabilities

Portal roles

Roles are assigned per organisation from users and roles.

There are six built-in roles, and each grants a set of capabilities. A capability is the unit each route actually checks, so this table is what the server enforces rather than a description of it. An Admin can also define custom roles, each of which grants whichever of the same capabilities it was given.

Capability	Covers	Admin	Editor	Marketing	Viewer	Compliance	Billing
Templates and signatures	Library, editor, drafts, versions, staged rollouts, images, import and export, preview, download, test email	Yes	Yes	No	No	No	No
Assignment rules	Which template each group or person gets, the org-wide role assignments, pausing delivery, and simulating a mailbox against the rules	Yes	No	No	No	No	No
Campaign banners	Scheduled promotional banners	Yes	No	Yes	No	No	No
Compliance footers	Legal and disclaimer footers, and whether a template carries one	Yes	No	No	No	Yes	No
Link click analytics	Click tracking and its reports	Yes	No	Yes	Yes	No	No
Monitoring	Activity feed, attribute coverage, audit log	Yes	Yes	No	Yes	Yes	No
Users and roles	Invite users and assign roles	Yes	No	No	No	No	Yes
Billing	Plan, seats, subscription, billing profile and add-ons	Yes	No	No	No	No	Yes
Cost management	Which mailboxes and Entra groups have Sigil, which way round that list reads, and the suggestions behind it	Yes	No	No	No	No	Yes
Settings	The organisation-wide switches (publish approval, profile editing, the health digest and product update emails), which profile fields exist, and the branded link domain	Yes	No	No	No	No	No
Staff profile details	See and correct what a named colleague entered in their own profile fields	Yes	No	No	No	No	No

Admin is the only built-in role that holds every capability. Assignment rules, settings and staff profile details are the three capabilities no other built-in role holds. Rules decide who receives which signature, and whether anybody receives one at all, and settings decide who may publish, so both have organisation-wide reach that a narrower role should not.

Staff profile details is separate from users and roles for a different reason, and the Billing role is that reason. Billing holds the users capability, because the person paying for Sigil is usually the person deciding who has access to it, and it is otherwise kept clear of anything that changes what a colleague’s outgoing mail says. Editing somebody’s pronouns or their personal booking link is squarely the second thing, so putting it under the users capability would have handed it to a role built to avoid exactly that. Hence a capability of its own.

Defining which fields exist stays under settings, and the two come apart in practice: somebody can be trusted to correct a wrong number without also deciding what the organisation asks its staff for.

Billing and settings come apart the same way over the branded link domain. Buying or dropping the add-on is a billing decision and sits under billing; claiming the hostname that then appears in everybody’s outgoing mail is a settings one. The Billing role can therefore decide what the organisation pays for without being able to change what a signature links to.

Where publish approval is switched on, holding the templates capability is no longer enough to put a body live. Publishing, restoring a version, starting or promoting a staged rollout and scheduling any of it then need the Admin role, or a partner Owner or Admin working inside a managed client, while everything else an Editor does is unchanged.

Cost management is deliberately its own capability rather than part of billing. The two travel together for a tenant, where the Admin and Billing roles hold both, but they come apart for a partner: a managed client’s dormant mailboxes are its provider’s to trim, while its card and invoices are not its provider’s to see. Note that it is also the one capability outside templates that changes what a colleague’s outgoing mail looks like, which is why every use of it is written to the change log.

Only an Admin can create, change or remove another Admin. A Billing role holds the users capability and can manage ordinary colleagues, but cannot promote anybody to Admin, including a second account of their own.

A valid sign-in with no role assigned is authenticated but authorised for nothing, and is told to request access. A sign-in from an organisation that never granted consent is prompted to connect it instead.

There is one page no role is needed for. Where an organisation has switched profile editing on, anybody in it can open portal.usesigil.app/me and fill in their own signature details. That page consults no role and grants none: it acts only on the mailbox in the token that opened it, and somebody with no role who signs in there still reaches nothing else in the portal. It is deliberately kept clear of the path that promotes the first administrator, so opening it can never make an ordinary colleague one.

Help is open to every role, and so is ask the documentation. A Viewer gets stuck as readily as an Admin, and an answer describes the documentation rather than your organisation’s data, so there is nothing there to restrict.

The portal hides navigation a role cannot reach. Every server route independently checks the capability it requires, so hiding a menu item is presentation rather than the control.

Custom roles

A custom role is a named set of capabilities from the table above, defined by an Admin in users and roles. Any of the eleven can be given to one, including the three only Admin holds among the built-in roles. A route checks a custom role’s capabilities exactly as it checks a built-in role’s, so wherever these pages say a task needs, for example, the Admin, Editor, Viewer or Compliance role, a custom role holding the same capability can do it too.

What a custom role cannot reach is the authority that belongs to the Admin role itself rather than to a capability: managing Admins, accepting the data processing agreement, creating API keys, defining custom roles, rejecting a submitted draft, the getting started checklist, and publishing while publish approval is switched on. Those stay with Admins, and with a partner’s Owners and Admins working inside a managed client.

A person still holds exactly one role. Somebody who needs the access of two is given a custom role that combines them. An organisation can define up to 20.

API keys hold capabilities and no role

An API key is the one principal in Sigil that is not a person. It carries a set of capabilities drawn from the same table above, chosen when it is created, and it holds no role at all.

That distinction decides part of what a key cannot reach. Anything guarded by the Admin role rather than by a capability is refused to a key however its access is set: rejecting a submitted draft, the getting started checklist, accepting the data processing agreement, managing keys, and every publish path while publish approval is switched on.

A second limit sits on top of the capabilities, and it has no equivalent for a person. A key may only call operations on an allow-list, so holding a capability is necessary rather than sufficient. The template capability, for instance, reaches most of the signature library under a key but not the per-mailbox download, the preview against a real address or the test email, all of which a person holding the same capability can still use. The same split runs through profile fields: a key holding settings can define the fields, while reading or writing what a named colleague entered in one is refused. Staff profile details is offered when you create a key, because the portal offers whatever the administrator holds, but every operation it covers is off the allow-list, so a key granted it reaches nothing through it. See API keys for the whole list and the reasoning behind it.

A key can never be granted access its creator does not hold, and only an Admin can create one. There is deliberately no capability for key management that a narrower role could come to hold, because issuing a credential is a question about access rather than an area of the product.

A key also carries a read-only flag that is independent of its capabilities. With it set, the key can read every area it was given and write to none of them.

Partner roles

Partner roles apply across a managed client base. See partner roles.

Area	Owner	Admin	Technician	Billing
Work inside a managed client at all	Yes	Yes	Yes	No
Exclude a client’s mailboxes from Sigil	Yes	Yes	No	No
Create an API key inside a managed client	Yes	Yes	No	No
Switch a client’s branded link domain add-on on or off	Yes	Yes	Yes	No
Add, invite, transfer or release a client	Yes	Yes	No	No
Partner billing and invoice details	Yes	No	No	Yes
Usage and rebilling export	Yes	No	No	Yes
Manage partner staff	Yes	No	No	No

Inside a client, Owner, Admin and Technician reach templates, rules, banners, footers, analytics, monitoring and what the client’s staff entered in their profile fields. Owner and Admin additionally reach the client’s own users and roles, its settings and its cost management; a Technician reaches none of the three. No partner role reaches a client’s billing, because a managed client has no subscription of its own. Partner Billing staff reach nothing at all inside a client, staff profile details included.

A Technician is deliberately kept out of settings and cost management. Turning a client’s publish approval off is exactly the kind of change that control exists to prevent, and switching off a mailbox’s signature is an account decision rather than signature work. Both belong with the roles that also decide who has access.

Staff profile details is the one that goes the other way, and it is why the capability exists at all. Correcting a client’s wrong number while somebody is on leave is a service desk call rather than an account decision, so a Technician can do it. Deciding which fields the client is asked for sits under settings, so a Technician cannot. That asymmetry is visible in the portal: a Technician opening Profile fields gets the half showing what people entered and not the half defining the fields.

Any staff member can also be scoped to particular clients, whatever their role. Somebody with no scope set reaches every client of the partner; somebody scoped reaches only the clients listed against them.

Partner staff never appear in a client’s user list. Their capabilities inside a client come from their partner role rather than from anything the client granted, so removing somebody at the MSP removes their access to every client at once.

Vendor operator tiers

Tophhie Cloud’s own staff have a separate, tiered access list. It is not something a customer configures, but it is relevant to a security review.

Capability	Support	Operator
Read-only console, overview, health, exceptions	Yes	Yes
Preview, audit, notes, export	Yes	Yes
Read-only impersonation, expiring after 30 minutes	Yes	Yes
Message a tenant’s administrators, resend consent	Yes	Yes
Suspend, reactivate, reprovision, rename	No	Yes
Billing levers such as seat correction and discounts	No	Yes
Deprovision or purge a tenant	No	Yes

Destructive actions additionally require a fresh interactive re-authentication. The last operator cannot be removed or demoted, so the console cannot lock itself out. See compliance.