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.coto 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 neededMail.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
.sppkgfile. 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.