Managing clients

The Clients view is the partner workbench. One row per managed client, and the way into any of them.

What the client list shows

Each row carries the client’s name and primary domain, the seat count last recorded for them, whether they have a published template, and how many people hold a portal role in their organisation. A client whose tenant has been suspended is badged as such. Alongside each row are Manage, which opens the client, and a menu holding Release.

The seat figure is the last one the daily count recorded rather than a live number, so a client added today shows no seats until the next count runs.

A client that is not being billed to you is badged too, since its seats sit at nought on your aggregate whatever the seat figure beside it says. Where that arrangement runs to a date, the badge names it, as in “Free until 14 Oct 2026”, and the seats count from that date. The nightly billing run picks the change up. An open-ended one reads “Not billed” instead.

That date is the one thing worth planning around, which is why it is on the row rather than somewhere you would have to go looking. An extended trial for a client you are onboarding is the usual reason for one, and the day it lapses is the day your invoice grows.

Exemptions are set by Tophhie Cloud rather than in the partner console, so ask support for one. They lift by themselves on the date agreed rather than needing anybody to remember.

Because the bill that grows is yours, the emails about it come to you rather than to the client: one a week before the date, naming the client and the day, and another when the exemption ends. They go to your Owner and Billing staff and your billing email. The second also arrives if Tophhie Cloud lifts an exemption early. See emails Sigil sends.

Beyond that the list is deliberately narrow. It tells you whether a client is set up and how large they are, and nothing about their add-in activity or open exceptions. A client whose signatures have stopped for some reason other than never being published looks the same here as one that is fine, so a problem of that kind shows in the client’s own attribute coverage and activity views rather than on this list.

Alongside Release, the row menu carries the switch for the branded link domain add-on. See enabling an add-on for a client.

Adding a client

You cannot grant admin consent inside somebody else’s Entra tenant. Only an administrator of that tenant can, so onboarding is an invite flow.

Add the client with their name and, if you have it, the client administrator’s email address. Sigil issues a single-use invitation that expires after 14 days.

Give an address and Sigil emails the invitation for you. Leave it out and you get the link back to pass on through your own channels, which is often what an MSP wants when the introduction is already in a thread of its own.

Owners and Admins can add a client, once the current partner agreement has been accepted.

1. Open Clients in the portal sidebar.
2. Choose Add a client.
3. Enter the Client organisation name.
4. Enter Their administrator’s email, or leave it blank to send the link yourself.
5. Choose Create invite.

With an address given, the invitation is emailed and the confirmation names the address it went to. Without one, the link is copied to your clipboard. Either way the invitation is listed under Pending invites & transfers on the Clients view until it is used, with Copy link beside it.

The client administrator follows it and grants admin consent for their own tenant. The tenant provisions itself as it would for any direct customer, on the ordinary trial in its own name, and the invitation is consumed.

Consent does not link the tenant to you on its own. It raises a management request in your name, which an Admin at the client answers in their own portal in the same way as a transfer. Approval is the moment the tenant moves onto your account and your invoice; until then you have no access to it, so a link followed by an organisation you were not invited to manage produces nothing but a request it can refuse.

1. The client administrator follows the invitation link.
2. They sign in with Microsoft and grant admin consent for their organisation.
3. They sign in to the Sigil portal, where a card at the top reads that your organisation has asked to manage their Sigil account.
4. They choose Approve.

Until they do, the request is listed under Pending invites & transfers as awaiting their approval, and you have no access to the tenant. Unlike a transfer, no email goes to the client’s admins about it, so they see the card only when they sign in. Like a transfer, it lapses after 14 days unanswered. Your firm is emailed when they consent, so you know to chase the approval. See what your firm is told. An invitation sent by a suspended partner is not honoured: the client is provisioned as a direct customer and no request is raised.

A pending invitation can be revoked before it is used.

1. Open Clients in the portal sidebar.
2. Under Pending invites & transfers, open the Invite actions menu on the invitation’s row.
3. Choose Revoke invite.

The link stops working at once.

An invitation is only honoured for an organisation that has genuinely granted consent. Microsoft’s consent redirect names the tenant it came back for, and that name alone is not proof of anything, so Sigil checks the named tenant against Microsoft directly before raising the request in your name. Where the check comes back definite that the organisation has not granted consent, no request is raised and your invitation is left unused so it can be used again. A new organisation is stopped before anything is created and shown a screen asking it to try again, which is usually all it takes while Microsoft finishes recording the consent. An organisation that already uses Sigil carries on as it was.

The check only refuses on a definite answer. A Microsoft outage, a timeout or a slow moment during consent all count as no answer rather than as evidence against the client, and the onboarding goes ahead with the management request raised. That asymmetry is deliberate: a real client should never lose a signup to a check that could not reach Microsoft, and the request still needs their Admin’s approval before anything changes hands.

The same fallback covers an invitation that fails for any other reason, such as one that has expired or was already used. The client is provisioned exactly as an invited one would be, a direct customer on the ordinary trial, only without a management request in your name, and you can request a transfer afterwards. It is the safe way round: the client’s signatures work either way, and only who pays is left to settle.

Working inside a client

Open a client and choose Manage. The portal switches into that client’s context.

Owners, Admins and Technicians can, for the clients in their scope. The Clients list itself shows every client your firm manages, including any outside your own scope. Manage is where scope is checked.

1. Open Clients in the portal sidebar.
2. Choose Manage on the client’s row.

Manage is refused with a message in three cases. “Accept the partner agreement before managing clients.” means the agreement in force has not been accepted yet, which an Owner fixes on the agreement card. “You aren’t assigned to this client.” means your scope does not include it. “This client’s access is suspended.” means the client organisation is suspended, and nobody can work inside it until that is lifted.

A Technician still sees Add a client, Request a transfer and Release client in the portal, but choosing them is refused with “You don’t have access to this area.” Those actions sit with Owners and Admins.

The portal opens the client’s Templates view. A banner at the top reads Managing, followed by the client’s name, and says that changes are recorded against your organisation. The Partner entries leave the sidebar while you are in a client’s context.

To come back out:

1. Choose Exit on the banner.

You land on the Clients view.

Every view works exactly as it does for a direct tenant: templates, the designer, rules, banners, footers, activity, coverage. There is no separate partner version of any of them.

A persistent banner shows which client you are editing, with a one-click exit back to the partner console. That banner matters more than it sounds; the views are identical, so the banner is what tells you whose signatures you are about to publish.

The context follows you into the drag-and-drop designer, which is a page of its own rather than part of the portal, and it survives a reload and the browser’s back button. The designer names the organisation you are working in along its top bar, in the same colours as the banner, so opening a template never leaves you guessing whose it is.

Your access is read-write, so everything you do inside a client is a real change to their signatures.

Owners and Admins can also create an API key inside a client, which is how work across a client base gets automated. A key belongs to the client rather than to you: it appears on their own list, flagged as created by their IT provider, and their Admin can revoke it. There is no key that spans several clients, so a provider with forty clients manages forty of them.

Every key your firm created inside a client is revoked when the partnership with that client ends, whichever side ends it. The client’s change log records each revocation, so an integration that stops working the day after a release has an explanation waiting.

Enabling an add-on for a client

Some features cost extra and are not included in the per-mailbox rate. There is one today, the branded link domain, which serves a client’s tracked links from a hostname of their own.

Enable it from the client’s row menu on the Clients view, under Enable branded link domain… Owners, Admins and Technicians can, and the current partner agreement has to be accepted first, because it adds a charge to your invoice.

1. Open Clients in the portal sidebar.
2. Open the Client actions menu on the client’s row.
3. Choose Enable branded link domain…
4. Choose Enable in the confirmation.

The confirmation says the add-on is added to your monthly invoice at your partner rate once the client has set a domain up. To take it off again, choose Disable branded link domain from the same menu and confirm with Disable.

A Technician can switch it on and cannot then set the hostname up inside the client, since that sits under the client’s settings and a Technician holds no settings capability. The client’s own administrators or one of your Owners or Admins does that part.

The client cannot enable it themselves, since your invoice is not theirs to add to. Once you have enabled it, the setup is theirs: the hostname is on their DNS and their administrators add it in their own Settings. Nothing happens, and nothing is charged, until they do.

Disabling it removes their domain and their tracked links return to the shared hostname on the next render. The confirmation names the hostname that is about to go, because links already sitting in mail that client has sent stop working with it.

Both directions are recorded in your partner audit log and in the client’s own change log, attributed to you rather than to them.

See partner billing for how it is charged.

Taking over an existing tenant

A client that already uses Sigil directly can be transferred to your management. Because that changes who is billed and who can administer the tenant, it needs the tenant’s own administrator to approve the request rather than happening on your say-so.

Name the organisation by its primary domain or by its Entra tenant id. Either works, and the tenant id is the way round a client who has since changed the domain on their Sigil account.

Owners and Admins can request a transfer, once the current partner agreement has been accepted.

1. Open Clients in the portal sidebar.
2. Choose Request a transfer.
3. Choose By domain or By tenant id.
4. Enter Their primary domain or Their Entra tenant id.
5. Choose Send request.

The confirmation says the request is sent and that their administrator has to approve it before anything moves. If no unmanaged organisation matches, you are told so and pointed at sending an invite instead. While it waits, the request is listed under Pending invites & transfers as awaiting their approval.

Their administrators are emailed the request and approve or decline it in their own portal. The request expires after 14 days if nobody answers, and an organisation can only have one pending at a time. A request that expired unanswered no longer counts, so you can send a fresh one straight away.

On their side, only an Admin at the organisation can answer, and a partner cannot answer on their behalf.

1. The client administrator signs in to the Sigil portal. A card at the top reads that your organisation has asked to manage their Sigil account.
2. They choose Approve or Decline.

Nothing moves until it is approved. A transfer request is a request, not a claim.

Approving it stops the organisation’s own subscription before its seats move onto your bill, so nobody pays twice for the same month. If that step fails, the organisation is not moved onto your billing: it is told plainly that it is still billed in its own name and to ask Tophhie Cloud to finish the link. That is deliberate. A tenant that moved onto partner billing while its own subscription was still running would be invoiced twice with no way to unpick it.

The request itself is used up by the approval, though. It leaves your pending list and cannot be approved a second time, so finishing the move is Tophhie Cloud’s job rather than something the client can retry. Ask support if a client tells you they saw this message.

On approval, the client’s own administrators, everyone with its Billing role and its billing email are told that your firm now manages the account, and that its own subscription has stopped because you are billed from now on. The admin who approves is rarely the person who pays, so this is how the client’s finance contact learns that its invoices have ended.

What your firm is told

Your firm is emailed at each point where a client acts or a request runs out, so the Pending invites & transfers list is not the only way to find out. Each email goes to your Owners and Admins, and to the member of staff who sent the request or invitation if they are neither.

Email	Sent when
A named client has set up Sigil from your invitation	The client has granted consent. Says its administrator still has to approve your request, and that the request stays open for 14 days
A named client is now one of your Sigil clients	An administrator at the client approved your request. Names them, and says whether its mailboxes count towards your bill from today or it is exempt
A named client declined your request to manage its Sigil account	An administrator at the client declined. Nothing changes on either side, and you can ask again
Your request to manage a named client on Sigil has expired	A transfer request went 14 days unanswered
Your Sigil invitation to a named client has expired	An invitation went unused until it expired. Send a new one if they still want to join
A named client no longer has you managing its Sigil account	An administrator at the client removed your firm. Names them, and says your staff have lost access and its mailboxes no longer count towards your bill

The two expiry emails come from a morning check, and only for requests and invitations that ran out in the past week. Anything that ran out longer ago than that is not reported, so you never receive a backlog of old news.

Taking back a client you previously managed

An organisation that has already left your management, whether you released it, handed it back, or it removed your access itself, is treated differently from a new one. Relinking it hands your staff back access to their directory and moves their bill, and the organisation is not asked at the point the link is made.

So the ordinary route back is the transfer request above, which the client approves for itself. Tophhie Cloud can also relink by hand, but only at the organisation’s own request, and an operator has to confirm they hold that request before the link is made. Clause 7.2 of the partner agreement commits to that in writing, and the console enforces it rather than leaving it to memory.

Releasing a client

Releasing removes the partner link. The tenant reverts to a direct tenant, and its billing becomes its own responsibility again.

Your staff lose access to that client immediately. Their signatures keep working, and they get the same grace period a client-initiated departure gets, so somebody who did not choose this has time to add a card before anything stops.

Their administrators are emailed, so a release is never something a client discovers by noticing. Owners and Admins can release; a Technician cannot. Like managing a client, releasing one needs the current partner agreement accepted. If a new version is waiting for an Owner, Release is refused with “Accept the partner agreement before managing clients.” until they accept it.

1. Open Clients in the portal sidebar.
2. Open the Client actions menu on the client’s row.
3. Choose Release client.
4. Choose Release in the confirmation.

The confirmation says you lose access immediately, that billing returns to them, and that they need to add a payment method to keep signatures running. The client leaves your list.

Do this when a relationship ends, so the client is not left unable to administer their own signatures and you are not left paying for them.

Tophhie Cloud can also release a client on the same terms, one at a time. That exists for the case where you cannot: a partner whose staff are locked out cannot release anybody, and their clients would otherwise be stranded under a partnership that is ending. The client sees no difference either way, because it is the same release, with the same return to direct billing, the same grace period and the same email to their administrators. See leaving the programme.

A client can end it too

A managed client’s own administrator can remove your access without asking you.

On their side it takes an Admin.

1. The client administrator signs in to the Sigil portal. A card at the top reads Managed by, followed by your organisation’s name.
2. They choose Remove their access.
3. They choose Remove access in the confirmation.

That is deliberate rather than an oversight. The client is the data controller, and a controller has to be able to end a processor relationship it no longer wants. Needing the processor’s cooperation to do so would not be much of a right.

When it happens, the tenant returns to direct billing with a grace period to add a card, and the action is recorded in the partner audit trail. Their seats stop counting toward your subscription from that point.

Your own tenant

Your MSP’s own signatures live in a normal tenant, separate from the partner record. You manage it exactly as any customer manages theirs.

Audit

Partner-level actions are recorded in an append-only log: clients added, clients released, staff granted access, discounts changed.

Changes you make inside a client are recorded in that client’s own change log, so the client can see what was changed and when.

A client’s administrators are also emailed directly for the three events they must not learn about only by noticing: a transfer request, a release, and their provider’s billing failing. See emails Sigil sends.