Partner roles

Partner staff are people at the MSP, authenticated from the MSP’s own Entra tenant. Each is given a partner role that applies across the client base.

The four roles

Role	Grants
Owner	Everything: the client lifecycle, partner billing, staff management and accepting the partner agreement
Admin	The client lifecycle and full configuration inside a client, but not partner billing or staff management
Technician	Signature work inside a client, and correcting what its staff entered about themselves. No client lifecycle, no client user management, no billing
Billing	Partner billing and per-client usage reports only. No access inside a client at all

The client lifecycle means adding a client, inviting one, asking to take over an existing tenant, and releasing one. Owner and Admin both hold it.

Owner and Admin reach the same things inside a client. Where they differ is at partner level: only an Owner touches the partner subscription or the staff list, and only an Owner can accept the partner agreement. Accepting it commits the MSP commercially and under data protection law, which is not a signature a service desk shift should be able to give.

A Technician reaches templates, rules, banners, footers, link analytics and monitoring inside a client, but not that client’s own users and roles, not its settings, and not its cost management. Turning a client’s publish approval off is exactly the kind of change that control exists to prevent, and excluding a mailbox switches off a colleague’s signature, so both sit with the roles that also decide who has access.

A Technician can also see and correct what a client’s staff entered in their own profile fields. “She is on leave and her number is wrong” is a service desk call rather than an account decision, and it would be a strange programme that routed it to the partner Owner. Defining which fields a client asks for is settings work, so a Technician does not get that half: they arrive on the page able to fix a value and not to change the form.

No partner role reaches a managed client’s billing, because a managed client has no subscription of its own. The money is handled at partner level.

Cost management is the one deliberate exception, and the reason it is a separate permission from billing. A managed client’s seats are carried on your consolidated bill, so excluding its dormant mailboxes is your decision to take. Owner and Admin can do it without ever being shown that client’s card, invoices or subscription, none of which any partner role reaches.

The split follows the shape most MSP programmes use, which means it usually maps onto how an MSP is already organised: an owner or two, service desk technicians doing the day-to-day work, and somebody in finance who needs the numbers and nothing else.

What a partner role is not

A partner role is not a role inside a client’s tenant.

Partner staff never appear in a client’s user list. Their access comes from the partner link, and the capabilities they get inside a client are derived from their partner role rather than from anything the client granted.

The practical consequence: removing somebody at the MSP removes their access to every client at once, with nothing to clean up in each client’s tenant.

Client scoping

Staff can be scoped to a subset of clients rather than all of them, which is the usual arrangement for technicians on a large client base.

Scoping is set per person rather than per role. Somebody with no scope set reaches every client of the partner; somebody scoped can only work inside the clients listed against them. Choosing Manage on any other client is refused with “You aren’t assigned to this client.”

A scope narrows who can work inside a client. It does not narrow the Clients view itself, which lists every client of the partner to everyone who can open it, and it is not checked when a client is released or an add-on is switched on or off. Those actions follow the role alone, so an Admin scoped to ten clients can still release a client outside those ten.

It applies to the three roles that reach clients at all, so an Owner, an Admin or a Technician can each be narrowed. The Billing role cannot, because it has no access inside any client to narrow. A scope list against a Billing user would read as though it granted something, so the console does not offer one and a scope sent for that role is discarded rather than stored.

One gap: moving a scoped Owner, Admin or Technician to Billing leaves their old scope in place, and it still shows under Client access on the staff list. It grants nothing, since Billing reaches no client. Clear the scope before you change the role if you want the list to read cleanly.

Managing staff

Owners manage the staff list from Partner staff in the console. Adding somebody needs their email address and a role.

1. Open Partner staff in the portal sidebar.
2. Choose Add staff.
3. Enter their Email address. It must be a mailbox in your own organisation.
4. Pick a Role.
5. Under Client access, switch on the clients they may reach, or leave every switch off for access to all clients. The list is not shown for the Billing role.
6. Choose Save.

They appear in the list with their role and, under Client access, either the clients named or All clients.

Somebody new to the list is emailed a welcome, “You’ve been added to” your partner’s name “on Sigil”. It names you as the person who added them, gives their role with a line on what it covers, and tells them to sign in with their Microsoft work account. Changing an existing member’s role or scope sends nothing. To change somebody’s role or scope, add them again with the same email address: the form is titled Add or update staff, and saving replaces what was there. You cannot change your own role.

To remove somebody:

1. Open Partner staff in the portal sidebar.
2. Choose Remove on their row.
3. Choose Remove in the confirmation.

They lose access to every client immediately. You cannot remove yourself, and a partner must keep at least one Owner.

The same page holds the partner’s product update switch, which only Owners can change in the console. With it on, which is the default, the partner’s Owners and Admins receive the occasional round-up of what has changed in Sigil, and turning it off stops them for all partner staff. It does not change what a client’s own administrators receive, since they decide in their own settings, and anybody can still stop product updates for their own address from the link at the bottom of one. See emails Sigil sends.

1. Open Partner staff in the portal sidebar.
2. Under Product update emails, switch Send product update emails to your owners and admins on or off.

The change is saved as soon as the switch moves.

Tophhie Cloud can also turn the switch off for you, if you would rather ask than find it. The change is recorded in your partner event log against the person at Tophhie Cloud who made it.

When nobody can manage the staff list

Two situations lock a partner out of its own staff list, and neither can be fixed from the console:

• Nobody holds a partner role at all. The first administrator of your own tenant to sign in normally becomes the Owner, so this only happens when that sign-in never came.
• Your only Owner has left the firm. The console will not remove or demote the last Owner, so the role stays with an address nobody reads. That address is the one asked to accept a revised partner agreement, and it receives payment and dormancy notices.

In either case Tophhie Cloud can seat somebody on your behalf.

1. Contact Tophhie Cloud through portal.usesigil.app/support.
2. Give the email address of the person to add, which must be a mailbox in your own organisation since that is where they sign in, and the role they should have.
3. If the Owner who left should go, say so. Tophhie Cloud adds the new Owner first and removes the old one second, because the last-Owner rule applies to it as well.

Every change made this way is written to your partner event log, naming the person at Tophhie Cloud who made it, so an Owner nobody at your firm remembers adding has a recorded origin. Once an Owner is back, run the staff list from the console as usual.

Partner staff and their own tenant

Being partner staff and being an administrator of the MSP’s own Sigil tenant are separate things, and most people at an MSP are both. An engineer administers your own signatures through the normal tenant views and your clients’ through the partner console.

Compared with operator access

Tophhie Cloud’s own support staff have a separate mechanism entirely: a read-only “view as tenant” session that expires on the server after 30 minutes.

Partner access is read-write and not time-boxed, because a partner is administering their clients rather than supporting them from outside. The two are distinct paths with distinct guards.