Glow CloudKit Customer portal

Install guide

Each app ships as a single .sppkg package deployed tenant-wide (available on every site - no per-site "Add app" step). There are two ways to install:

Either way, it runs in your tenant - nothing goes through our servers.

Before you start

Option A - install in the browser (no PowerShell)

1. Download the package

  1. Sign in to the customer portal.
  2. Go to Downloads and click Download .sppkg for each app you want.

2. Upload to the App Catalog

  1. Open your App Catalog site → Apps for SharePoint.
  2. Drag the .sppkg in (or Upload).
  3. In the dialog, tick "Make this solution available to all sites in the organization", then Deploy.

Tick the "all sites" box. These packages use tenant-wide deployment - the older per-site "Add an app" flow will error.

2b. Make the Header render site-wide

The Header renders through a SharePoint Application Customizer, which runs from a tenant "Tenant Wide Extensions" entry. SharePoint doesn't always create that automatically on deploy, so register it once (Header-only - Theme, Directory and Agenda are web parts you add to a page):

Easiest: add the Header Designer web part to any page, open the Advanced tab, and click Register header extension tenant-wide. You must be an App Catalog site admin. That's it.

Prefer to do it by hand? It's still just clicks - in your App Catalog site go to Site contents → Tenant Wide Extensions → New and enter:

Allow ~15-30 minutes for SharePoint to activate the extension across sites.

2c. Hub inheritance & multiple hubs (optional)

The Header can be authored once on a hub and inherited by every associated spoke - turn on "Apply to associated sites" in the Designer. For that to work for all users, the header settings must be stored where everyone can read them. In the Header Designer's Advanced tab, use Set tenant config site to point it at one site that's readable by everyone who'll see the header (a Communication site is ideal) - do this before designing headers.

Running several independent hub-and-spoke structures in one tenant is fully supported: design a separate header on each hub, and each hub (with its own spokes) gets its own header automatically - they don't interfere with each other.

Option B - one command (PowerShell)

On the portal Downloads page, the Install apps panel gives you a ready-to-run command (your tenant and the sign-in app are pre-filled) plus the installer download. It deploys your apps, registers the Header extension, sets up the config site and approves every permission your apps requested in one go - running as you, on your machine, in your tenant.

  1. Install the module once: Install-Module PnP.PowerShell -Scope CurrentUser.
  2. Download the installer and the apps you want into one folder.
  3. Unblock the installer. Windows marks any file downloaded through a browser, and PowerShell refuses to run it. In that folder, run:
    Unblock-File .\Install-SharePointKit.ps1
  4. Copy the pre-filled command from the portal and run it from that folder; sign in when prompted. If PowerShell still says "running scripts is disabled on this system", your machine's execution policy is blocking it - start a session that allows it for that window only:
    powershell -ExecutionPolicy Bypass
    then run the command again. This changes nothing permanently and needs no admin rights.

Sign-in uses our multi-tenant installer app - you consent to it once in your tenant, with no Entra app registration on your side (prefer your own app? the installer's README shows how to pass one). The installer only deploys the packages you place in the folder.

3. Approve API permissions

(Option B's installer does this for you - it approves whatever your apps requested, whichever they are.) Most of the kit needs no Graph permissions at all. Nine apps request a small, read-only set, and they only ask for it once deployed:

  1. Go to the SharePoint admin center → Advanced → API access.
  2. Approve the pending requests listed there. They appear after you deploy, not before.
  3. This step needs a Global Administrator. A SharePoint Administrator can open the page and see the requests but cannot approve them - approving grants tenant-wide Graph consent. If that is not you, this is the one step to hand to whoever holds the role.
AppRequestsIf you skip it
DirectoryUser.Read.All, Presence.Read.All, User-LifeCycleInfo.Read.AllThe directory cannot load people
Org ChartUser.Read.All, Presence.Read.AllThe chart cannot load; it tells you which permission is missing
AgendaCalendars.Read.Shared, Group.Read.AllSharePoint list sources still work; mailbox and group calendars do not
Newsroom, Announce, Launchpad, FAQ Builder, Showcase, SpotlightGroupMember.Read.AllThe web part works normally, but audience targeting silently shows everything to everyone - it fails open by design, so nobody is locked out of content

Every other app - Cheers, Greetings, Header, Prism, Pulse, Section, Social, Theme and WorldKit - needs nothing approved. If an app is not in the table above, there is no permissions step for it.

4. Add the app to a page

Upgrading to a new version

When a new version is released, download the latest .sppkg and upload it to the App Catalog - choose Replace. Because the package identifiers are unchanged, this is an in-place upgrade: your existing instances and settings are preserved. Approve any new API permissions if prompted.

Then do one hard refresh - Ctrl + F5 on Windows, or Cmd + Shift + R on a Mac - on a page that uses the web parts. An upgrade gives the app's files new names, and a browser still holding the previous version will keep asking for the old ones. An ordinary refresh reuses that cache, so it has to be a hard one. It is needed once per person, and anyone who does not do it picks the new version up on their own as their cache expires.

Worth mentioning to your team when you upgrade rather than waiting to be asked. If a web part looks wrong or is missing text immediately after an upgrade, a hard refresh is almost always the answer.

Next: how licensing & activation works →