SharePoint 2010 Goes Social, Part 1

SharePoint Server 2010 introduces many new features to support social networking. In the first part of this three-part article, I look at the major requirements for social networking and introduce the User Profile Service, which provides one of the foundations for such networking. In the second article I’ll discuss how to populate the User Profile through synchronization with LDAP-compliant directories, and in the third article I’ll describe the major features that are used to better exploit a major information asset of any organization—its people. Note that the social networking features described in these articles are available only with a SharePoint Server 2010 installation and aren’t available in a SharePoint Foundation 2010–only deployment.

Social Networking Requirements

Social networking is all about people. It’s about finding the right people and the best information sources to use to deliver business goals. Often, finding the right people is achieved through a journey of discovery (or some might say a journey of frustration!) that leverages the social connections that exist between people and the skills and expertise they possess. A common challenge in large organizations is that the connections between people are often tacit (i.e., not written down and known only inside the heads of individuals); no definitive source exists for registering the skills that people have or those that they develop as they progress through their careers.

SharePoint Server 2010 was designed with the social side of information sharing in mind. It provides many features that can be used to find the right people to do the right job by treating people as a significant intellectual asset and placing them at the center of any collaboration. Finding information about people, including who they know and the skills they possess, is usually just a click away. I say “usually” because building such a social network that ultimately delivers value doesn’t just happen by merely installing SharePoint. It requires the buy-in of everyone—from executive support, to IT, to end users—such that the full wealth of the organization can be leveraged. To generate the greatest value, a network’s scope must be across an entire organization and be viewed as a social networking hub. Half-hearted deployments typically result in frustrated users who don’t see the value in using the system.

SharePoint architects and administrators therefore need to think about how information about people will be captured and how this information will be kept up-to-date so that it’s vibrant and accurately reflects the current intellectual wealth of the organization. If information is correctly gathered and managed, then the organization as a whole benefits because SharePoint takes a people-centric approach, offering linkages between other people and resources. SharePoint helps you understand the social context between you and other people who contribute to your organization’s collateral, which can help you build stronger relationships—sometimes with others who you might not have even known existed before you embarked on your information-gathering task.

Importance of the User Profile

Leveraging people as information assets requires a flexible central store that can hold data about the people in an organization. The data held in such a store needs to be gathered from multiple sources, because it’s common for different types of information about people to be held in special-purpose repositories. For example, project information about projects that people worked on might be held in a different database than organizational information, and people skills and interests might exist only inside the heads of individuals.

The User Profile is at the heart of SharePoint Server 2010’s social networking features and is where the vast majority of information about people is stored. The User Profile Service application, managed through SharePoint Central Administration, controls many people-centric features, such as maintenance of entries in the User Profile, synchronization of the profile with other repositories, and My Site settings (which I’ll discuss in the last article in this series). Figure 1 shows the management page of the User Profile Service. Note that some options are also displayed to manage organization profiles; however, I don’t discuss this feature because it isn’t fully implemented in SharePoint 2010.

Figure 1: User Profile Service management

When a User Profile Service application is initially provisioned, three main SQL Server databases are created to hold people and social information:

You can think of the User Profile as a special-purpose SharePoint list that acts as a directory for people. Its contents can be fuelled from multiple sources, such as AD, other LDAP-compliant sources, and Microsoft Business Connectivity Services (BCS), through synchronization. Developers can also use many techniques to allow profile updates from other applications, and end users can be authorized to update their own directory entries from their My Site. (A common misconception is that the User Profile is required or involved when authorizing access to a SharePoint site. However, no requirement exists to implement the profile in authorizing access to SharePoint content.)

The User Profile is defined in terms of user properties. You can modify the default set of properties to add other pertinent properties that will help people become better connected. Typically, you’d add properties to hold data that you could either populate and maintain automatically or that the end users themselves could manage. For the latter to be successful, users must know the intended purpose of the property so they can provide pertinent data. What this all boils down to is that there’s no point in adding properties to a profile unless you strongly believe they will be useable, maintainable, useful, and will add value. To maximize SharePoint’s social networking capabilities, you should ensure that the data held inside the User Profile is rich, relevant, up-to-date, and, most importantly, exhaustive across everyone in your organization.

User Subtypes

Unlike in previous versions of SharePoint, in SharePoint 2010 you can have more than one type of User Profile, through the use of User Subtypes. A User Subtype essentially consists of a subset of all the default and custom-defined user properties. You can define as many User Subtypes as necessary to meet your needs, which lets you store different data about different types of people.

All out-of-the box and custom properties are initially assigned to all User Subtypes. The User Subtype that’s defined out of the box is called the Default User Profile Subtype. This means that when you create a new User Subtype, all existing properties are automatically assigned to it. You must then remove any existing properties that you don’t want assigned. As you create new properties, you can select which existing User Subtypes the properties should apply to; the Default User Profile Subtype is automatically selected by default. As an example, you might decide to add a new User Subtype for part-time employees, then add a new property that holds those employees’ working days. You’d then apply the new property only to the part-time employees subtype.

The User Subtype is essentially used as a filter to determine which properties to display because, technically, all User Profile properties are actually associated with every entry in the User Profile. This means that if you change the User Subtype that a User Profile entry is linked with, then change it back again, the original properties associated with the User Subtype will retain their original values. This clearly must be the case if user properties can be associated with more than one User Subtype.

Properties and Attributes

As you create custom user properties (or modify default properties) through the Manage User Properties option, you need to consider the attributes to be applied to the property. These attributes control where and how the user property is used.

The Type attribute defines the type of data that the user property will hold. There are many valid data types, including text, dates, and person. The person data type requires that any data associated with the property be a link to another User Profile. The Term Set attribute leverages the new Managed Metadata service and ensures that the data in the property is consistent. As an example, you could create a term set that contained the days of the week to hold the possible values for the part-time employee scenario described earlier.

Policy settings control how the property is used in terms of whether it requires a value, whether the user can override the value, and its privacy setting. Privacy settings control who is allowed to see the property; privacy settings can be set to one of the following values:

I’ll discuss the effect of these privacy settings in the third article in this series.

Another policy setting determines whether a property is replicable (i.e., whether its value will be replicated to the user details that are held in site collections, such as team sites, blogs, etc., defined in the SharePoint farm). A property can replicate only if the user isn’t allowed to override its value (to avoid inconsistencies) and if its privacy policy is set to Everyone (because there’s no ability to limit who can see user details in a site collection).

Display settings control where a property is displayed. One interesting setting that I’ll cover in the third article in this series is the ability to display updates to the property value in a user’s newsfeed. (A newsfeed is like an RSS subscription to user activities so that you can follow what other people are up to.)

Synchronization settings control whether a property is mapped to an external data source for import and export purposes. I’ll cover synchronization settings in the second article in the series.

Options for Populating the User Profile

Various methods are available to initially populate the User Profile. The method you decide to use depends on the size of your organization and whether you have some other people directories deployed that might contain definitive information. You can manually add User Profiles through Central Administration, or they can be dynamically created when suitably permissioned users access their My Site for the first time. As I mentioned, other options include populating the profile programmatically via the object model or the User Profile Service web service. You can also populate the profile through synchronization with AD and other LDAP-compliant repositories, as well as external sources using BCS. Synchronizing with AD is the subject of the second article in this three-part series.