Let’s Capture Missing or Insufficient SharePoint REST Endpoints

Today I got an alert that the SharePoint UserVoice suggestion from Corey Roth (@coreyroth) entitled Add managed metadata term store operations to REST API got the coveted “Thinking About It” tag from the Product Group. I like to tweet out changes like this to let people know the Product Group is listening and acting on our feedback – beyond saying “That’s good feedback!” It’s not all wine and roses, though:

Thank you for your feedback! Just letting you know that we absolutely have this in our backlog, but unfortunately this currently is not included in our short term engineering tasks. We absolutely understand the request and seeing vote counts around this, will help to further prioritize this work for next sprints.

I got a couple of tweets back right away pointing out some other current holes in the REST APIs.

If you think there are other endpoints the REST APIs need or endpoints that don’t work well, please add them to the comments here. I’ll work them up into a list for the Product Group and let’s see what we can get moving! We’ll play by the rules and add the list to UserVoice, but I think all the individual suggestions get lost and it’s harder to see the bigger picture. For each item on the list, I’ve tried to capture related UserVoice suggestions.

The list so far:


  • Ability to use $filter on Calculated column and Single value Taxonomy column label (@gautamdsheth)
  • Enable support for lookup columns in other webs in the REST API (Me!) https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/9065329-enable-support-for-lookup-columns-in-other-webs-in
  • Create list item in a folder (@jfj1997)



  • Version history (@merill) – Provide the Version History feature on list items with CSOM and/or REST, i.e. provide which metadata has changed with the previous value. Currently, the only way to retrieve versions is through the FileVersionCollection/FileVersion objects which provides only the VersionLabel, CreatedBy, CreationDate and Version Url. Ideally, we would need a ListItem object holding all the attributes and values for each version. (John Gunning)


Managed Metadata / Taxonomy


  • Recurring events via the Search endpoint (Derek Gusoff)


  • Publishing – PublishingPageContent, PublishingPageImage (@gautamdsheth)


  • Starting a site workflow – StartWorkflowOnListItemBySubscriptionId & StartWorkflow are only for list items (@BradOrluk)

Microsoft Graph

  • Easily get a graph access token (anonymous)


  • SharePoint groups – Changing group owners has a bug such that you can’t change them using REST (Mike)

User Profiles

  • Allow custom user profile property to be filtered using the $filter parameter (@gautamdsheth)


  • Edit and manage web parts (anonymous)

Movement on the SharePoint List 5000 Item Limit!

In October, Eric Alexander (@ejaya2) posted an idea to the SharePoint UserVoice called Prioritize large list management in SharePoint Online. Yesterday I received an alert about it because I had voted for it.

The 5000 item limit has been an albatross around our necks since SharePoint 2010. SharePoint 2007 was the wild west days: we could pile as many items into a list as we wanted and retrieve them without a problem, though perhaps at the expense of performance.

I’ve railed about this limit many times in the past, like here.

No 5000 item limit

If you search the SharePoint UserVoice for “5000“, you’ll find no fewer than 14 suggestions circling this topic. There are probably even more, but without the number 5000 in them.

Luckily, our good friends in Redmond know this is an issue for us. As of yesterday, Eric’s suggestion moved to “Working on it”, at least for SharePoint Online.

Prioritize large list management in SharePoint Online - Working on it




I’m looking forward to what happens here. As Eric notes in his suggestion:

If nothing can be done, then TechNet NEEDS to indicate that the actual limit of SharePoint Online lists and libraries is 5,000 items, not the current architectural limit of 30 million.

The more we want to use SharePoint as a service (SPaaS?), the more important it becomes to get past this limitation.

I’m certain that the work Dan Kogan (@kogandan) and his team are doing on the SharePoint Framework (SPFx) has made it obvious that this limit is a serious issue. (Sometimes you have to take the albatross off your neck and slap someone with it.)

Image from http://elkgrovegovernment.com/with-the-nrc-announcement-has-the-albatross-been-taken-off-elk-groves-neck/

Image from http://elkgrovegovernment.com/with-the-nrc-announcement-has-the-albatross-been-taken-off-elk-groves-neck/

Adding Geolocation Columns to SharePoint Lists

One of the cool things that came along in SharePoint 2013 was Geolocation fields in lists. Using Geolocation fields, we can display Map Views in SharePoint lists. This capability is an awesome way to add visualization to your UI and can really add value in many business processes.

Map View

Image Source: http://msdn.microsoft.com/en-us/library/office/jj656773(v=office.15).aspx

Think about it. You could show:

  • A map of your customers in a region
  • A map of your office’s location on its Intranet page
  • Deliveries you’ve made in the last 30 days
  • etc.

Unfortunately, at the present time in SharePoint 2013 on premises and SharePoint Online (Office365), “The Geolocation column is not available by default in SharePoint lists. To add the column to a SharePoint list, you have to write code.” (See How to: Add a Geolocation column to a list programmatically in SharePoint 2013)

For whatever reason, there’s no way to add a new Geolocation field via the UI. Instead you have to go through some hoops with PowerShell or script. See the following articles for great tutelage on how to do this:

As I understand it, there’s an MSI package (SQLSysClrTypes.msi)that must be installed manually on the Web Front Ends (WFEs) in an on premises installation to enable Geolocation fields, but this is already in place in SharePoint Online. Given this, we should be able to add Geolocation columns to lists via the UI without PowerShell or admin intervention.

This doesn’t sit well with me. At some of my clients, getting an admin to add something to the WFEs or run PowerShell requires an act of Congress. These Geolocation capabilities are too powerful a SharePoint feature to keep them under wraps.

To wit, I’ve created a suggestion called Adding Geolocation Fields to SharePoint Lists on the Office Development UserVoice site. If you’d like to be able to use Geolocation fields in your SharePoint solutions – at least on Office365 – head on over and cast your vote(s). Remember, Microsoft is listening!