Why SharePoint 2010 Social Features Suck

Over the last year or so, I’ve spent more time on the new SharePoint 2010 social features than I believe I have spent on any other technology. Ever. In this blog post, I thought I’d sum up my findings and thoughts. I’ll try to do this as non-technical as possible, but please bear with me if I get a bit passionate about details.


The last year, I’ve been working on what was one of the largest SharePoint 2010 implementations in the world. I’ve been part of a team that has worked on the bleeding edge of technology (bullshit bingo: scratch one) trying to see how much oomph we can get from the new platform.

Our task has been to implement a highly customized ‘My Site’ host. If you don’t know, the My Site host is the interface to most of the new fancy social features, like all the personal features, colleagues, tags and notes, user profiles, and activities.

We’ve worked in-depth with virtually all of the new features, including creating custom applications that utilize tagging to create bookmark and ‘favorite’ sites, extending the activity feed to more closely resemble the FaceBook wall (spoiler alert: the SharePoint activity feed is nothing like a FaceBook wall, despite appearances), creating custom event engines for tracking user profile completion, and of course extensive branding, of which you know I had no part.

Microsoft 1.0

When you have been around technology for a while, you start recognizing personalities in companies. You can say a lot about Microsoft, most of them good in my opinion, but one thing that can’t be said enough is what many call the ‘Microsoft 1.0’ phenomena. Honestly, I haven’t seen it described in so many words in recent years, but it was a common description a few years back.

The Microsoft 1.0 phenomena is a description of the first version of something that Microsoft creates. You can easily recognize the aforementioned personality in that software. First of all, the code is always riddled with seemingly weird decisions or quirks. Second, it always contains a number of issues that you know will be changed in future versions. Third, you’ll see the evolution of earlier ideas, and this is particularly visible when you look at major new features in an existing piece of software, like the introduction of social features (major new feature) in SharePoint 2010 (existing piece of software).

However, Microsoft 1.0 code is always visionary. You can see in the code the ideas that Microsoft has and the direction that a product will take. You see that the people developing has had the idea of what to do although they may have missed the target in their initial shot at implementing that idea.

I likely couldn’t do any better myself, by the way. I’ve written enough software to know that when you try to implement an idea you have, you’re going to need a few versions of the software before you find elegant solutions.

SharePoint 2010 1.0 Features

Let me describe a few examples of what I mean.

In SharePoint 2007, particularly in the MOSS features, you had the idea for Manager objects for various tasks. A commonly used object was the UserProfileManager (UPM), responsible for working with user profiles in MOSS.

The UPM had its quirks and wasn’t necessarily intuitive to use, especially when it came to handling user profile fields. This has to do with the legacy of earlier versions, but suffice to say, it did require some of that ‘get used to it’ effort. These days, most seasoned MOSS developers can probably list all the properties, methods _and_ overloads of those methods for the UPM. The masters can also cite the exceptions thrown.

The *Manager idea is far more visible in SharePoint 2010. Most of the new social features have Manager objects and as a developer, this will be your common access points to those features. Here you have an example of where an idea, quirkily implemented in earlier versions, expands into a mature feature in later versions.

Working with social tagging, commenting and rating is intuitive, easy, and fun. Even custom managed metadata solutions gives you plenty of ‘Hm… That was easy’ moments.

Oh, and of course, the *Manager idea isn’t unique to SharePoint, or even Microsoft.  I am trying to stay away from too technical descriptions, though.

The way many of the manager objects for SharePoint 2010 social features are implemented, though, will likely be up for revision in future versions. This will lead to complications for upgrade of code, but if there is one thing Microsoft knows, it is how to handle backwards compatibility (or at least market why the change is a good idea).

The same can be said for claims based authentication. In previous versions, setting up a user profile service in MOSS was about as difficult as spelling your own name. With the new fancy authentication setup, it is worth a blog post whenever you manage to set up user profiles in one go, and I’ve seen entire installations get cancelled because of the complexity of setting up the user profile synchronization. It’s a 1.0 feature, containing plenty of quirks (or bugs), and you know it’s going to change in the future.

Then, there’s the activity feed.

You Promised Suckage!

OK, well, I really did that because I wanted to point out the immaturity in the technical bits of SP2010 social features. To not scare away too many of the non-techies, though, I’ll try to keep this light.

So, let’s look at the activity feed. Great idea, easy to market (it’s FaceBook for the enterprise, how cool is that?), but a completely bonkers implementation.

If you don’t care about the details, skip to the end of the post, because the rest of this is just gritty bits of engine design.

If you are still here, try this: Try to get the activity feed to behave like the FaceBook activity feed and add simple things like a ‘Like’ or ‘Comment’ functionality to the feed. Go ahead, I’ll wait here.

Oh, are you done with that? Try creating an ad-hoc filter of the activity feed, for example to implement a ‘Social Groups’ functionality where a temporary team, say the people in an organization responsible for the next department annual review, can organize their activities into a single activity feed.

It turns out that the way the activity feed is implemented is so locked down and restricted that seemingly simple extensions like these are virtually impossible to create.

One specific example is how the activity feed actually behaves in three distinct modes, each really being a completely different piece of functionality. Add to that the fact that the data you see in one ‘mode’ isn’t even related to what appears to be exactly the same data in another mode, and you’re quickly beginning to see some problematic areas.

Here’s a scenario: John, The Manager, updates his profile with a new status note, saying ‘I’m on vacation in July’. When that status note is displayed in the activity feed that is displayed on John’s profile page, the update has one distinct ID property that uniquely identifies it.

[John’s Profile Page]
John: I’m on vacation in July

Now, let’s say that John is in your social network and you get his updates in your activity feed. You see John’s activity like this:

[Your Activity Feed]
: I’m on vacation in July

However, what you are seeing has nothing to do with the update that is displayed on John’s profile page. The update you see in your activity feed has a different ID and there is no connection between the two ID values. Not just is it a different ID, but it’s a totally different database. Not that I’ve checked, of course, because doing so will void your supportability.

Thus, if you implement an extended functionality where you can go to John’s page and ‘Like’ his update, you won’t be able to propagate
that ‘Like’ to other version of the exact same update, because there is no connection between John’s version and your version of the same update.

It gets worse still. You aren’t just getting the two versions of the same update, there are more. I’ll happily admit not having verified this, but from what I can see, you actually get one version of the update per privacy level that can see the update. For an update visible to everyone, that means you get 6 unique updates, with no correlation to each other. . So, to extend our example above:

[John’s Profile Page]
John: I’m on vacation in July (activity id: 45)

[Your Activity Feed]
: I’m on vacation in July (activity id: 82)

[John’s Manager’s Activity Feed]
: I’m on vacation in July (activity id: 83)

I’ll likely check this further and post an updated blog post or a journal or something. When I have time.

Before you think you can easily detect the similarities between the updates, however, read on.

Here’s a second example, the ad-hoc group filtering thing I mentioned above. When you want to get the activities to display as part of an activity feed, you have three options. Get activities for yourself (1), which are the activities displayed in your network, get activities you have posted (2), which is a privacy filtered view of the updates you have made, or get activities that a particular user has done (3), as seen by another user.

That’s it.

You can’t, for example, say ‘Give me activities for Alice, Bob, and Claire’ unless you create three distinct activity feeds (option three above, times three). You could add these users to your colleagues and get your activity feed (first option above) and then filter these events by Alice, Bob, and Claire, but your activity feed may not contain any recent updates from those users and you’d get no result at all.

This also means that the trick with detecting which of the many updates are the same update doesn’t work, because you have no easy way to get every update from a feed. You get items from the activity feed based on the context you run your code. If you are a colleague, you get updates published up to and including the colleague level, but not for the manager level, for example.

A final item to ponder is the rendering of those activity feed items. They are pre-rendered for you and unless you plan to write your own rendering engine, which I can tell you from personal experience is possible but quite a lot of work, your only options are to get the entire event, pre-rendered, either in text or HTML format.

Now, I actually understand the reason why Microsoft chose to do the activity feed this way, and it has to do with privacy and performance. The two activity feed databases separate between published activities (which are the ones you see on the user’s profile page) and the consolidated activities (which are the ones you see on the ‘Updates from Your Network’ feed)

That’s fine, but it does put a serious dampener on the idea that the activity feed of SharePoint 2010 would resemble anything close to a FaceBook wall. Personally, I think it plain sucks, because the the idea behind the activity feed is actually very beautiful, but it is tainted by being a 1.0 feature and not particularly well implemented.

My prediction is that SharePoint 2013 (codename SharePoint vNext) will change how those activities are generated. At least I hope so, because the vision is definitely there.


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

8 thoughts on “Why SharePoint 2010 Social Features Suck”

  1. You are absolutely right that the user profile service is so buggy that it derails installs. We're fighting that fight right now.

    I completely agree with the uselessness of the activity feed, though I'm not a fan of Facebook either.

    What's really scary to me though, is that in some installation configurations, the user profile service will be completely deprovisioned and made unworkable during a farm backup. Say bye bye to the user profiles!

  2. This comment is long over due and I've had it on my mind the past weeks.

    Wouldn't it have been better to use the "discussion forums" backend as a facebook like social app with postings and comments? One thread per post with post #1 as the status and replies as the comments.

  3. Mikael,

    Is your suggestino to swap the activity feed for a forum? Although that may sound feasible, there is a lot of stuff going on in the activity feed, not the least of which is performance and privacy optimizations. Implementing this in a forum would at best be tedious and would not perform well at all.

    Keep in mind that an activity feed for 10K users could perhaps generate an average of 5-10 entries per day. That would give you 50-100K entries per day and would quickly reach the limits of even optimized SharePoint lists.


  4. Great article. I want to make sure I understand what you are saying. I am currently attempting to set up a “community” page for an organization. They want a facebook type activity feed in the middle of this page that shows conversations. Now they haven’t quite defined what conversations they want but I know at least they want to see everyone’s “what’s happening” or activity feed. It sounds like it can’t be done without setting it up for every individual.

    I tried this – http:///_layouts/activityfeed.aspx?consolidated=true but I am not even getting my colleagues feeds in the RSS reader.

    1. Sonia,

      It’s very difficult to debug via comments on a blog, but my advise, if you are looking to get a community system up and running, is to wait for SP2013, which has huge improvments both to community management and to FaceBook-like features.


Leave a Reply

Your email address will not be published.