I just recently experienced this error. I am on Office 365 so using the latest SharePoint version that is deployed on my tenant.

This occurs in the app-environment in one of the add-ins I am working on. A couple of weeks ago this wasn't a issue. I have already granted the add-in read permissions for "User Profiles (Social)" that should be enough to read the current user profile.

(1) This query worked before, but now it gives me access denied error:

System.UnauthorizedAccessException: Access denied. You do not have permission to perform this action or access this resource.

(2) For the sake of testing this too had the same outcome as (1):


If I test with the main domain, everything is fine, as expected:


So the issue seems narrowed down to unable to access SP.UserProfiles.PeopleManager from the app environment.

Note that whilst writing this post, I noticed that simply CTRL+F5 refreshing the page from the (1) example URL, most of the time it would show me access denied exception, but then it would suddenly show me the expected data. Same behavior goes for (2). This looks very odd, and it persisted trying other browsers and incognito/private modes to make sure there were no cookie issues.

Right now I'd like to hear from others that might have the same issue or similar. It's important to me that this doesn't remain unnoticed.

  • We are experiencing the same problem, beginning from yesterday morning, also with the same solution – trembon Mar 14 '17 at 7:20

Our customer had the same problem when loading the user properties from the GetMyProperties method. We were calling the method with the following code:

var spContext = SP.ClientContext.get_current();
var peopleManager = new SP.UserProfiles.PeopleManager(spContext);
var currentUserProperties = peopleManager.getMyProperties();


After some research on alterntives with the possibility to call the GetMyProperties in the context of the main site, I started trying to just fetch the properties we needed, after all in our case we only used 2 or 3 properties from the profile.

With the following code we are able to query SharePoint for user properties from the context of an app.

var spContext = SP.ClientContext.get_current();
var peopleManager = new SP.UserProfiles.PeopleManager(spContext);
var userProfilePropertiesForUser = new SP.UserProfiles.UserProfilePropertiesForUser(spContext, 'i:0#.f|membership|' + _spPageContextInfo.userEmail, ["SPS-Department", "SPS-JobTitle"]);
var propertyArray = peopleManager.getUserProfilePropertiesFor(userProfilePropertiesForUser);


What we are doing here is requesting a few specific properties for a selected user, which in our case is still the current user. Hope this code can help you to.

NOTE1: This is just installed in our customers environment, but is showing promising result for our case.

NOTE2: This code is translated from TypeScript and may have a typo or two :)

| improve this answer | |
  • I tested using the REST equivalent of GetPropertiesFor instead of GetMyProperties, but the same behavior persists. Considering JSOM uses another endpoint and method of communicating with SharePoint, I suspect that a recently deployed update introduced a bug, but only in the REST environment. (Maybe not a problem with the REST method, but most likely a permission scoping error, given as giving read to Tenant scope fixes the issue. It's a whole new topic why you'd even grant Tenant to your add-in if you only need to read one field from the current users profile... – Alex Pedersen Mar 17 '17 at 9:01
  • Though I had the same problem with GetPropertiesFor, which loads the complete profile, but the code in my answer only loads the specified properties for a user, not the complete profile. But it might give this error depending on which field you want to access. – trembon Mar 20 '17 at 14:08
  • You are correct. It seems that the PersonalUrl was causing issues on my end, so only selecting the fields I really needed, the issue is buypassed. I'd draw this up to a bug of some sort, since the query works 1 out of 20 tries. Selecting just the fields I need, it works like expected. :) – Alex Pedersen Apr 20 '17 at 9:29

I had the same issue, struggling for last two days.

It worked for me with read permission on tenant for the SharePoint Addin.

enter image description here

Do try this.

| improve this answer | |
  • That would give the add-in read access to all permission scopes for the whole tenancy. The thing with scopes is... that they are scopes? So it might be a solution, but is it really a good one? – trembon Mar 15 '17 at 15:26
  • Yeah it will give read access for whole tenancy, But this is the only workaround I found till now. I have already raised a ticket about this issue to Microsoft but they are unable to resolve it. – Avinash Sah Mar 16 '17 at 5:04
  • Have you tried the solution I posted? Seems to work for the case our customer uses which didn't require any change in the scopes – trembon Mar 16 '17 at 8:29

The various posts in the thread provide some insight to buypassing the issue.

Setting the permission scope solves the issue, but the underlying problem is still there.

In my use-case I discovered that adding a query parameter $select and requesting the specific fields I needed, avoided triggering the underlying error that made the entire request fail 19 out of every 20 tries.

Believe it or not the field PersonalUrl caused issues for me, and there might be additional fields that might do the same. The easiest way is to try specifically fetch each field you need, until the request fails, then you know where the issue lies.

I still believe this is a bug somewhere deep inside SharePoint, and that this is yet again a way to avoid triggering the exception. For now this is good enough for me to move forward. :)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.