Skip to content

Connect your organisation

Onboarding is self-serve. There is no provisioning call, no account to be created for you, and no credentials to exchange. A Microsoft 365 administrator grants consent and the tenant provisions itself.

The free trial button on Sigil’s website opens the portal’s trial screen rather than the usual sign-in. It is headed “Start your 14-day free trial” and sets out what you are agreeing to before anybody signs in:

Card Not needed to try Sigil. Add payment details before the trial ends to keep signatures running
What you need Microsoft 365 with Exchange Online, and an administrator who can approve directory access and deploy the Outlook add-in
Where to work A desktop browser, to customise your signature
How long the add-in takes Up to 72 hours for Microsoft to distribute it

The screen also links to the permissions Sigil needs. Your organisation’s trial starts when an administrator connects Microsoft 365, not when you open this screen.

If you are the administrator:

  1. Choose Continue with Microsoft and sign in with your work account.
  2. On the screen headed “One more step to set up”, choose Approve as an administrator and approve on Microsoft’s screen.
  3. You arrive on the Getting started checklist.

If somebody else will have to approve it:

  1. Choose “Copy setup link for your IT admin”. The button reads Link copied.
  2. A box appears under the card with the link in it. If your browser blocked the copy, select the link in the box and copy it yourself.
  3. Send the link to your Microsoft 365 administrator. It opens the same trial screen for them, so they can read what is being asked before they sign in.

The setup link is also the easy way to move from a phone to a desktop: open it on the desktop and carry on there.

Go to:

https://portal.usesigil.app/admin/consent

You are redirected to Microsoft’s admin consent screen for Sigil’s multi-tenant Entra application. It lists the permissions being requested. All of them are read-only; Sigil never requests write access to your directory. See permissions for what each one is for and why it is the narrowest that works.

Granting consent installs Sigil’s service principal in your tenant. That is what lets the signature service read directory attributes for your users.

Consent is tenant-wide, so Microsoft only accepts it from an administrator who holds that right. A Privileged Role Administrator or Global Administrator can; most other roles cannot, and Microsoft turns them away at its own screen with an AADSTS error rather than letting the attempt through to Sigil. See requirements.

Signed in to Microsoft 365 as an administrator who can grant consent tenant-wide:

  1. Open https://portal.usesigil.app/admin/consent in your browser.
  2. On Microsoft’s consent screen, check the organisation named and review the permissions listed, then approve.
  3. You are returned to the portal. It shows “Your organisation is connected” and sends you to Microsoft to sign in.
  4. Sign in with your Microsoft work account. You arrive on the Getting started checklist.

If you had already signed in to the portal before granting consent, step 3 takes you straight into the checklist instead. A colleague who already has a role other than Admin is taken to the first page their role can open, because the checklist is for Admins only.

The consent callback sets your tenant up before you have signed in:

It creates the tenant record, keyed by your Entra tenant id.

It starts a trial subscription with real seats from day one. Nothing is charged until the trial ends.

It pre-fills your billing profile from your organisation’s registered address in Entra, so the invoice details are mostly right before you look at them.

It seeds a starter signature: a polished, editable design rather than a blank page or a bare default.

The subscription is the one step that does not finish before you are sent to the portal. It is several calls to Stripe, and the only part of provisioning that depends on a service outside Sigil, so it runs as a job of its own and completes moments after you arrive. Nothing you can see is waiting on it, and a Stripe failure that clears in a minute is retried without anybody having to notice.

Only the tenant record is essential. The other steps can fail on their own without stopping the rest, which is why an organisation occasionally lands in the portal with a working template library and no billing set up. Sigil records which step failed and emails Tophhie Cloud support at the moment it happens, once the retries are exhausted rather than at the first sign of trouble, so this is normally fixed before you notice it. If something looks half-configured on your first day, that is worth mentioning rather than working around.

One step commonly comes back empty: reading your organisation’s name and address from Entra. Microsoft has not always finished propagating the consent by the time it is asked, so a brand new tenant is sometimes named after its GUID for a few minutes. The real name is filled in the first time an administrator signs in. Sigil retries directory reads once with a fresh token for the same reason, which covers the window where consent is granted but not yet live.

Go to:

https://portal.usesigil.app/admin

Sign in with your Microsoft account. There is no separate password, and no directory sync. The portal is a single-page app that signs you in with MSAL and sends the resulting token on every API call.

The first person to sign in after consent becomes the tenant administrator. From there they can invite colleagues and assign roles under users and roles.

You land on the Getting started checklist, which walks through the remaining steps.

Signing in and being authorised are separate things. Your Entra token establishes who you are and which organisation you belong to. Your role, stored per tenant in Sigil, decides what you can do.

Situation What happens
You have a role in a connected tenant You get the portal, scoped to that role
You sign in with no role assigned You are told to request access from an administrator
Your organisation never granted consent You get a second step offering to approve Sigil, which starts consent
Your organisation was removed and is awaiting deletion You are told to contact support, because only an operator can restore it
Your organisation is suspended You see “Couldn’t load your account”, with a message saying your organisation’s access is suspended

Reaching the portal before anyone has granted consent is the ordinary order of events for an administrator who was forwarded a link, so that case offers the consent step rather than an error. No role and removal cannot be resolved by the person reading them, and say so without offering a button. A suspension shows a Reload button, but reloading will not lift it. Contact support instead.

That step is presented as step two of two, with your sign-in ticked off above it and the account you signed in with named, because the alternative reads as the sign-in screen appearing a second time and the natural conclusion is that signing in failed. It also names your domain, so you can see which organisation is about to be connected.

The screen says that a Global Administrator or Privileged Role Administrator can grant consent. If you are neither, it offers to copy a setup link so you can send it to somebody who is. That is the commonest dead end here, and it is worth using rather than pressing the approve button and reading back an AADSTS code. The link opens the trial screen described under starting from the free trial, so your administrator sees what Sigil asks for before signing in. It deliberately carries no account details, since the point is for a different person to open it.

To connect your organisation from that screen:

  1. Open https://portal.usesigil.app/admin and choose Sign in with Microsoft.
  2. On the screen headed “One more step to set up”, check that the domain named is the organisation you mean to connect.
  3. Choose Approve as an administrator.
  4. Approve the consent on Microsoft’s screen.
  5. You are returned to the portal, signed in.

If you cannot approve it yourself:

  1. On the same screen choose “Not an administrator? Copy the link”. The button reads Link copied, and a box appears under the card with the link in it. If your browser blocked the copy, select the link in the box and copy it.
  2. Send the link to an administrator who can grant consent. They open it, choose Continue with Microsoft, then Approve as an administrator.
  3. Once they have approved on Microsoft’s screen, sign in again.

If Microsoft turns the attempt away, you are sent back to the portal with a short message and a reference. Quote that reference to support. It identifies the exact attempt in Sigil’s onboarding log, which holds what Microsoft returned, how far provisioning got and how long each step took, so the first reply can be an answer rather than a request for more detail. The commonest cause is an administrator who cannot grant consent tenant-wide. Closing the consent screen without deciding records nothing against your organisation, and the link can simply be opened again.

When you are sent back to the portal after a failed attempt:

  1. Read the message on the screen headed “Setting up didn’t finish”. Where it carries a reference, note it down.
  2. Choose Reload.
  3. Open the consent link again as an administrator who can approve it. If the attempt fails the same way, contact support and quote the reference.

One outcome is worth recognising because it looks like a failure and is not. Before setting up an organisation it has never seen, Sigil asks Microsoft whether Sigil is actually installed in the directory the redirect named. Microsoft’s redirect is unsigned, and the tenant id in it is public, so without that question anybody could have an organisation’s record created and its trial started before the organisation itself ever arrived.

If Microsoft answers definitely that Sigil is not in that directory, and still says so when asked again a couple of seconds later, nothing is created and you are returned to the portal with a message saying the consent could not be verified yet. Opening the consent link again is the whole remedy. If Microsoft cannot answer at all, through an outage or a timeout, provisioning goes ahead as normal, because an unanswered question is not evidence against a real customer.

That screen is headed “We couldn’t confirm the connection yet”:

  1. Choose Reload.
  2. Sign in with Microsoft if you are asked to.
  3. On the “One more step to set up” screen, choose Approve as an administrator and approve on Microsoft’s screen again.

An organisation that is already connected is never refused on this basis, so a signature service already in use cannot be affected by it.

A failure on Sigil’s side after consent succeeded looks different, because it is not something you can act on. You are returned to the portal as though everything worked, and depending on how far provisioning got, you either sign in normally or find your organisation is not connected yet. This is the case the support alert above exists for. If your first sign-in looks wrong in any way, contact support rather than granting consent again.

Where you arrived from an invitation rather than signing up directly, either from an IT provider taking your organisation on or from a partner invitation to your own firm, one extra check runs before the invitation is honoured.

Microsoft’s consent redirect names the tenant it came back for, and nothing about that name is signed, so Sigil asks Microsoft whether that organisation really has granted consent before acting on an invitation for it. Without the check, holding an invitation and knowing a tenant id, which is public, would be enough to claim an organisation that had never heard of the invitation.

If the answer is definite that no consent exists, what happens depends on whether Sigil already knows your organisation. A new organisation is stopped before anything is created, on the “We couldn’t confirm the connection yet” screen described above, and retrying is the remedy. An organisation that is already connected carries on as it was. Either way the invitation is not applied and is left unused, so it still works once consent is in place.

An IT provider’s invitation never hands your organisation over by itself. Once consent is confirmed, it raises a management request in the provider’s name. Your first administrator to sign in sees it and approves or declines it, and the provider has no access to your tenant until it is approved. See adding a client.

If Microsoft cannot answer, through an outage, a timeout or the moments while consent is still propagating, the invitation is honoured as normal. An unanswered check is not treated as evidence against an organisation, because the cost of getting that wrong falls on a real customer at the worst possible moment.

Consent can be revoked, either deliberately or as a side effect of tidying up enterprise applications in Entra. When that happens Sigil can no longer read your directory, and signatures break quietly: the template is still there, but there is no data to personalise it with.

A nightly scan checks whether Sigil can still read each organisation’s directory. The first night it is refused, every administrator is emailed “Action needed: reconnect Sigil” with a Reconnect Sigil button. That happens once per lapse rather than every night, and a night when Microsoft does not answer at all sends nothing. Tophhie Cloud support can send the same link again by hand. If you suspect this has happened, re-visiting /admin/consent and granting consent again restores it, without waiting for the email.

To grant consent again from the portal:

  1. Open Getting started in the portal sidebar. The Connect Microsoft 365 step is unticked while Sigil cannot read your directory.
  2. Choose Grant admin consent.
  3. Approve on Microsoft’s screen.
  4. You are returned to the portal.

Opening https://portal.usesigil.app/admin/consent directly does the same thing. Nothing else about your organisation changes, and the next section says what re-consenting cannot fix.

Re-consenting restores directory access, which is the problem above. It changes nothing else about your organisation in Sigil, and two cases in particular look as though it should help when it will not.

It does not lift a suspension, and it does not bring back an organisation that has been removed and is inside its deletion grace window. In both cases Microsoft accepts the consent and Sigil records the attempt, so the flow appears to succeed while your access stays exactly as it was. Restoring a removed organisation is an operator action. Contact support instead.

Consent can be withdrawn at any time from Entra, under Enterprise applications. Withdrawing it stops Sigil reading your directory, which stops signatures being rendered.

To remove the product properly, also remove the add-in from Integrated apps and cancel the subscription from the Billing view. If you want your data deleted rather than dormant, contact support and ask for the tenant to be deprovisioned; that cancels billing and purges every record, asset and cached entry belonging to your organisation. Two records are deliberately kept, and data and privacy says which and why.

Coming back after the purge is a new signup rather than a restoration. Granting consent again provisions a fresh organisation, with a fresh trial and no templates, rules or history from before.

A deprovision normally waits out a grace window of 30 days before the purge runs. During that window your organisation is still on record as awaiting deletion, so granting consent again does not start a new signup, as described above. If you want to come back sooner, ask support to purge straight away, or to restore the organisation instead.