SpHUB Book a demo

Where SPHub stores your data

Every record SPHub creates lives in an ordinary SharePoint list inside your own Microsoft 365 tenant. There is no separate database, and no copy of your content on our servers. The one exception is a licence check, described below.

Content lives in SharePoint lists you own

SPHub content lives in SharePoint lists you can open, export, back up and audit with the tools you already use.

  • No separate database

    SPHub stores nothing of its own. Lists are only created for the modules you enable, and the install page covers what setup creates.

  • Your permissions stay as they are

    SharePoint decides who sees what. SPHub adds no permission model of its own, so an employee sees exactly what your existing groups already allow.

  • Nothing to migrate out

    Because the data is already in SharePoint lists, leaving SPHub does not require an export. Remove the web parts and the lists stay where they are.

  • Safe to run again

    Setup skips anything that already exists; the install page covers re-runs.

The one call that leaves your tenant

SPHub makes one call to a host outside Microsoft, a licence check, and it is stated here plainly because a security reviewer will ask about it first.

  • A licence check

    SPHub sends your Microsoft 365 tenant ID to licenses.sphub.co to confirm the installation is licensed. That is the only call the product makes to a host outside Microsoft.

  • What is not sent

    The tenant ID, and nothing else. The request is a single GET carrying one query parameter, and that parameter is your Microsoft 365 tenant ID — an opaque GUID Microsoft already assigns you, not a name or an address.

  • If the licence server is unreachable

    SPHub carries on. A failed check is treated as licensed and is not cached, so the next page load retries. An outage on our side does not take your intranet down with it.

  • Why it is worth saying

    SPHub is close to "your data never leaves your tenant", but not literally zero-egress, and we would rather you read that here than discover it in a network trace.

The three Graph permissions, and what each is for

A SharePoint administrator approves SPHub's three Microsoft Graph permissions once, in the SharePoint admin centre under API access. SPHub requests no others, and one module needs more than these three — both are set out below.

Microsoft Graph scopes

why it is needed
  • Mail.SendLets a module email a named contact person when a request is created or updated. Eleven modules can do this, and none sends anything until you configure a contact person.
  • User.ReadMicrosoft’s sign-in scope, which lets you sign in to the web parts. SPHub reads who you are from SharePoint itself, not from Graph.
  • People.ReadPowers the people pickers in module forms, which suggest colleagues from your own relevant-people list

One module needs more than these three, and we would rather you heard it here than found it after installing. The company directory reads your tenant’s user list from Graph, which Microsoft gates behind User.Read.All. SPHub does not request it: that permission reads every colleague’s full profile, and it is a bigger ask than the rest of the product needs. Approve the three above and the other 26 web parts work normally, while the directory shows an error instead of a list. If you want the directory, an administrator grants User.Read.All separately, to the shared SharePoint Online Client Extensibility principal that every SPFx solution in your tenant uses.

Where SPHub runs

  • SharePoint Online

    Modern pages, deployed from your own tenant App Catalog as a single .sppkg file. No custom script needs to be enabled.

  • Microsoft Teams

    Most web parts can be added as a Teams tab, where they follow the Teams theme; see the web parts page.

  • Not Outlook

    There is no Outlook host in any SPHub component.

See it run in a tenant you control

Install it on a development site and watch it create the lists, pages and menu, module by module.