Expanding People Column Fields In Sharepoint Rest Apis

The Problem: Limited Profile Information in Default Responses

The SharePoint REST APIs provide useful profile information for users, but the default people fields returned are limited. By default, the REST responses only contain a few identifying fields like ID, Name, Email, LoginName etc. However, SharePoint stores much more user profile data like Department, Skills, Past Projects, Start Date and so on. This additional contextual information can be very valuable for building custom solutions on top of SharePoint.

Adding Custom Profile Properties

SharePoint allows admins and developers to create custom user profile properties to store additional metadata for people columns. These custom attributes can hold information as text, numbers, dates, booleans etc. Below are the key steps to add custom columns to the user profile list:

1. Navigate to User Profiles in SharePoint Admin Center and select “Manage User Properties”
2. Click the option to add a custom property and provide a name, type etc
3. Choose whether to add to the default profile page and make it editable by users
4. Save the new property and propagate changes across site collections

Custom properties can also be created programmatically using CSOM, PowerShell or other APIs. This allows adding custom attributes as part ofprovisioning scripts or automating profile management tasks especially in larger deployments.

Retrieving Custom Properties Through REST

The SharePoint REST APIs do not return custom user profile properties by default. We need to explicitly request the additional fields we want using OData query parameters. The two key query parameters that help retrieve custom attributes are:

• $select – Used to limit or specify additional fields to return besides the default set
• $expand – Expand nested entities or attribute collections inline in the response

By carefully using $select and $expand, we can get profile information tailored to our specific needs rather than standard fields.

Example Request to Get Custom Properties

Below is a sample REST API request to retrieve custom Name, Department and StartDate properties from user profiles additionally along with the ID field:

GET: https://contoso.sharepoint.com/_api/Web/siteusers?$select=Id,Name,Department,StartDate

A typical JSON response would contain the custom attributes as additional fields in the results:

{
  "value": [
    {
      "Id": 4, 
      "Name": "John Doe",
      "Department": "Marketing",
      "StartDate": "2021-04-01"
    },
    {
      "Id": 11,
      "Name": "Jane Smith", 
      "Department": "Sales",
      "StartDate": "2020-12-05"
    }
  ]
}  

We can further process this response in code to extract the desired properties – below is a sample C# class to model this data:

public class User
{ 
  public int Id {get; set;}
  
  public string Name {get; set;}
   
  public string Department {get; set;}
   
  public DateTime StartDate {get; set;} 
}

By projecting the JSON results into such strongly typed classes, we can conveniently access the custom properties we want from REST along with default metadata.

Handling Large User Profiles

A downside of expanding user profiles is potentially large responses which can impact performance. Some strategies to handle this scenarios are:

• Use $select to only get required fields instead of all profile properties
• Retrieve a subset of users at a time with paging using $top and $skip
• Enable caching and prefetching to optimize repeated requests
• De-normalize data and store a copy of info needed for your app separately

Combining $top for pagination with $select for sparse fieldsets avoids expensive calls to return entire profile entities.

GET: https://contoso.sharepoint.com/_api/Web/siteusers?$top=100&$select=Id,Name,Department

This focuses on critical app fields but splits responses across pages for lighter payloads.

Customizing Display Names and Data Types

The raw JSON responses may not format custom properties ideally – they use internal names and represent values simplistically as strings. We can improve this by:

1. Setting DisplayName attributes on custom columns for user-friendly naming
2. Casting property values to appropriate CLR types in REST query

For example, formatting the StartDate field as a date:

GET: https://contoso.sharepoint.com/_api/Web/siteusers?$select=Id,Name,Department,StartDate/DateTime

This renders the profile information better for business users ultimately consuming the data from our apps.

Conclusion

Expanding SharePoint people columns allows integrating rich profile information in custom solutions. By using $select and $expand effectively, we can retrieve precisely the user attributes needed by our application. Careful data modeling and caching also helps manage large profile data payloads through REST APIs.

In addition to working with user profiles, similar OData query techniques can expand lookups to documents, events, directories and more. The SharePoint REST API proves highly flexible, especially as needs mature beyond standard columns.