2 Basics to Know About SharePoint Online App Permissions

Apps have been a certain strength in SharePoint Online as there are multiple options available for developers as well as users. The global store concept is implemented well, and it’s expected to reach more downloads in the future with many companies migrating to SharePoint Online.  Here are two basic things to know about SharePoint app permissions.

What Happens Behind an App?

A SharePoint app contains a sub site in a host site. That’s because when an app is created, it creates a sub site inside the host site. Therefore, an app has the facilities to create lists inside of it.

An app can also define properties inside it. The app sub site doesn’t have access to normal site content and site settings pages.

But if you’re the developer, and if you know the list name, you can access the list using the list url as in other sites, and read, add, edit, and delete items. You can add many pages to give a smooth user experience and add many script files as well as style sheets.

What is App Permission?

The introduction of the online store downloads brings some possible security risks. Common questions asked include

App permission management is the simplest answer for this. It lets the developer define a set of permission levels as needed to make the app fully functional.

Then the person who’s installing has the right to decide whether to allow the app to access that information before downloading.

SharePoint prompts with a page similar to the image above (see Figure 1) prior to installation.

What are the Permission Levels and Types?

The permission levels are quite similar to the ones that exist in user permissions. The five levels of SharePoint app permissions are None, Read, Write, Manage, and Full Control.

There are multiple permission types defined in a SharePoint app. They’re categorized as Content, Services, Social, and Project (see Figure 2). By default, all types are set to level None.

Content permissions can be defined for Tenant, Site Collection, Web, or List scopes. Child elements get permissions in higher elements at least. For example, if read permissions are given to the Web, all the lists in the site will get at least read permissions. That can be overridden by defining Write at list level, so the lists get write permissions. But once Web is set to Read, Defining List as None wouldn’t restrict access to lists.

Services permissions let the developer request permissions for Business Connectivity, Search, and Taxonomy services running in the on-premises farm or in an Office 365 tenant.

Social permissions need to be set to access the documents users follow (Core), posts, and activities by user or the team (News Feed), and User Profile information.

Project permissions are for managing the project server components. Unlike other permission types, this type has only one or two options. The types of permissions are Core, Enterprise Resources, Multiple Projects, Reporting, Single Project, Status Updates, and Workflow.

All in? Or Nothing?

Another fact about these permissions is that the permission levels need to be accepted or rejected in their entirety prior to installation.

For example, let’s say the app requests the Read permission level on Web and the Write permission level on List. As the installer, you don’t like giving Write permissions to lists, though you have no issues with giving Read permissions to the web—but you have no option other than not installing the app.

I think that makes sense given an app is a box full of functionality, and initially an app isn’t advanced enough to define micro functionality with different permission levels inside.

Sometimes there are tricks that will help to get rid of such situations. I will share some important tips and tricks in another article.

So what stops you from making your own app? Also, what stops you from trying out some cool apps already in the marketplace?