Site Collection App Catalog vs. Tenant App Catalog

By Anatoly Mironov

Site Collection App Catalogs are great for special cases (like developing apps or site unique apps), but using them on scale would be a mess.

I got a question: Why should we use the Tenant App Catalog at all when we could enable a Site Collection App Catalog on every teamsite? So the suggestion here is to install SharePoint Framework Packages on many Site Collection App Catalogs, instead of the Tenant App Catalog. In that way those wouldn’t be visible for all users in the “Add an app” page.

Technically, both ways are possible, but I would say, we should use the Tenant App Catalog for apps that are installed on many sites. I have gathered some pros and cons to help people decide.

But first, some abbreviations and notes on terminology:

  • SCAC = Site Collection App Catalog, (Local App Catalog)
  • TAC = Tenant App Catalog, (Global App Catalog)
  • App = SharePoint Framework Package, but also a SharePoint Add-In

Pros and Cons of Site Collection App Catalogs

👍 A SCAC makes it possible to have local instances of an app. It is perfect if you want to test an app without making it visible for the whole tenant. It is also good for apps that are only installed on one site collection. There are benefits of distributing site specific apps through the TAC, such as better governance, once installed on a site, those apps can be Disabled.

👎 Mess in all the apps and the versions. There might be different versions of the apps. The update procedure will require a special script to find all the sites and run the update. This also requires owner access to that site. If the owners would like to remove all the IT accounts in order to collaborate on confidential information, then it won’t be possible to update that site. It will lead to poor governance. Just to give it a perspective. Imagine that every smartphone had its own local App Store/Google Play. Possible but counterproductive.

👎 A SCAC is a security risk. The control and governance is handed over to site owners. It means that they can install any apps on their site collections. Poorly designed and implemented apps can lead to big security issues, in the similar way as custom script.

👎 Enabling a SCAC adds additional lists and features (such as Apps for SharePoint). It will require more space (not so much, but still), but first of all it will make some users more confused, actually more confused then some more available apps. Imagine all the support: What is it, Oops I deleted “Apps for SharePoint”.

👎 Every app will install the resources on every site collection, meaning every app will have multiple copies of the same app. It means more space needed. That is of course, not the case if you use Azure CDN.

👎 Every app will use its own urls to resources, preventing browsers from gaining performance by caching the resources cross site collections.

👎 If Azure CDN is used, you must make sure all the versions of javascript and css files are kept because you might not know which versions of an app are still used.

Pros and Cons of the Tenant App Catalog

👍 Easier to control the apps and have better governance. The Tenant App catalog tells what apps exist in your tenant. As admin you can verify that the code complies with the guidelines (by running code checks), you can make sure, every app there has all needed information such as app owner, description etc.

👍 Easier to update apps. Installing a new version of an app will update all the instances. There won’t be any custom script to traverse all the sites with that app.

👍 It is more cost efficient to follow the Tenant App Catalog approach, because it is the recommended way of installing and updating apps. Having scripts and procedures for SCAC, (even completely automated) will always cost more: to keep the scripts up to date, support etc.

👍 Benefits of the common apps. If a business unit comes up with a good solution, it can be used by other Business units, if it is discoverable and follows quality guidelines (more on that later).

👎 The Apps from the TAC are visible to all Business Units and the users might be confused. This issue can be mitigated in two ways:

  • The business units that have not rolled out SharePoint Online and don’t use any apps, can remove their users from the App Catalog.
  • Having a good naming policy, app icons, good descriptions, disabling any “auxiliary” apps. On top of that, some user guidance.

Summary of pros and cons

To summarize, Site Collection App Catalogs for reusable apps installed to many site collections, is a bad idea, because it means a security risk, less control and governance, encreased data and traffic to SharePoint Servers.

How can we scope apps to our business units

Are there other ways of scoping the apps to business units other than misusing the Site Collection App Catalogs?

First of all, it is a question of user adoption. It is better to help users instead of breaking the functionality or misusing other concepts.

Second, it is a question about governance of the Tenant App Catalog. It should be clear how an app can be added, and how that package should be wrapped:

  • good naming standard,
  • proper localization
  • a mandatory icon,
  • good description,
  • owner/contact person. Also, only relevant apps should be “Enabled”. All the other apps should be Disabled.

A couple of apps from your organization is a drop in the ocean compared to SharePoint Store Apps

Control with Permissions

If you remove a user from the Tenant App Catalog, the apps will disappear for that user.

There are apps, but this user cannot see any apps to install.

The permissions can set on the whole Tenant App Catalog by removing “Everyone except external users” and then adding all AD Groups who should see the apps.

The permissions could also be set on the specific packages or folders.

The permission way of scoping the apps might work. But it is important to know that it is a workaround and it breaks the default setup (where all users have READ on the TAC). This means that along the way you can bump into limitations or bugs, more or less unique to your organization. It will be harder to get help from Microsoft or from community.