Dissecting the new Graph API Endpoint for User Profile Customization

Hello everyone,

I've been exploring the recently introduced Graph API endpoints for customizing user profiles in Office 365. Specifically, I'm interested in the /beta/users/{id}/extensions endpoint and its capabilities for adding custom attributes.

I've managed to successfully create a simple extension with a string property, but I'm encountering issues when trying to add a complex object as a property. The documentation mentions support for complex types, but the examples are a bit sparse.

Has anyone had success with this? I'm trying to achieve something like this structure:

{ "@odata.type": "#microsoft.graph.openTypeExtension", "extensionName": "com.example.mydata", "departmentName": "Engineering", "projectDetails": { "projectName": "Phoenix", "startDate": "2023-10-01", "teamMembers": ["Alice", "Bob"] } }

When I send a POST request with this payload, I'm getting a 400 Bad Request with a message about invalid property type. Any insights or examples would be greatly appreciated!

Hi John,

Thanks for raising this! It's a common point of confusion. The Graph API, particularly with openTypeExtension, is quite strict about how complex types are serialized. When you're sending a complex object like projectDetails, you need to ensure that all its properties are themselves valid primitive types or other supported complex types.

The issue might be with the teamMembers array. While arrays of strings are generally supported, sometimes nested structures can cause parsing issues. Have you tried serializing the nested object into a JSON string before assigning it as a property?

For example, try this:

{
  "@odata.type": "#microsoft.graph.openTypeExtension",
  "extensionName": "com.example.mydata",
  "departmentName": "Engineering",
  "projectDetails": "{ \"projectName\": \"Phoenix\", \"startDate\": \"2023-10-01\", \"teamMembers\": [\"Alice\", \"Bob\"] }"
}
                

Alternatively, if you need a truly nested structure, consider using a custom extension type (defined in your application manifest) instead of openTypeExtension, as those offer more flexibility in defining schema.

Let me know if this helps!

Alice, that's a clever workaround! Serializing the complex object into a JSON string did the trick. I was able to successfully create the extension with the nested projectDetails.

I appreciate the suggestion about custom extension types as well. For this particular use case, the stringified JSON is sufficient, but I'll keep that in mind for future, more complex scenarios where a defined schema might be more robust.

Thank you for the quick and effective solution!

This is great to see! I was facing a similar problem with storing configuration objects. John, Alice, thanks for the discussion. Alice's JSON string workaround is excellent. I'll be using that immediately.

One quick follow-up question: when retrieving these extensions via GET /users/{id}/extensions, does the projectDetails property come back as a string that I then need to parse, or does the Graph API intelligently deserialize it back into an object?