“Input string was not in a correct format” error with People Picker and custom claim provider

In SharePoint 2013 I implemented a custom claim provider with search and resolve functionality and everything appeared to work fine. I was able to search and resolve users, grant them permissions to the site, and they were able to login successfully. Everything was good until a user reported a problem with the People Picker. When the user creates a task (in the OOTB Task list), and picks a user for the Assigned To field and save the item, they get the error message “Input string was not in a correct format” against the Assigned To field.

It turns out that this was because I was populating the PickerEntity objects with inappropriate values, namely UserId.

When implementing custom claim providers, you return search and resolve results to the People Picker by creating PickerEntity objects. This class has a property, namely EntityData, which is a Hashtable of additional information that you can populate for the particular user.

Typically you set a property in the EntityData table using a member of the PeopleEditorEntityDataKeys class, as shown below.

entity.EntityData[PeopleEditorEntityDataKeys.Email] = "user@test.com";
entity.EntityData[PeopleEditorEntityDataKeys.PrincipalType] = SPPrincipalType.User.ToString();

One of the members of the PeopleEditorEntityDataKeys class is UserId. I was setting this key to the login name for my user – and this is what caused the problem.

This key should be set to an integer, and should be the SPUser.ID property of the user – which means you typically would not set this key in a custom claim provider. I removed this key from the EntityData table for my users and the issue was resolved.

Other interesting observations

When you select a user, e.g. for the Assigned To field in this instance, and save the list item (or grant permission to the user), that user is created in the User Information List for the site collection if it doesn’t already exist (this list can be found at http://server/site/_catalogs/users). Some, not all, of the values you set in the PickerEntity.EntityData hashtable is actually used to populate the fields for the new user list item. In my testing however, only the PeopleEditorEntityDataKeys.Email and PeopleEditorEntityDataKeys.MobilePhone values work. Being able to set the Email for the user is really important though. It means that the user will straight away be able to receive notifications from SharePoint.

The other observation is that the People Picker seems to be doing some caching on the client side. If you are debugging your claim provider, it is best to test using a new browser session each time.


About Bernado

Based in Australia, I am a freelance SharePoint and Dynamics CRM developer. I love developing innovative solutions that address business and everyday problems. Feel free to contact me if you think I can help you with your SharePoint or CRM implementation.
This entry was posted in Claim Authentication, People Picker, SharePoint. Bookmark the permalink.

4 Responses to “Input string was not in a correct format” error with People Picker and custom claim provider

  1. Steve Butler says:

    Great post Bernado; we had been stuck with this exact same problem since January and concluded the same resolution as you by removing the ID set.
    Going a stage further – are you able to get the client-side people picker control to find any names in a sharepoint-hosted app?
    I’m only able to resolve and match “SharePoint Groups” if I include SPGroup in the PrincipalAccountType using the article shown here :


    Nothing is returned from “User” or “Group”.

    Any thoughts? (NB : we’ve disabled the native “AD” provider so that we only return users from the user profile service application). I’m suspecting this is the heart of my issue ….

    • Bernado says:

      Hi Steve,

      Unfortunately I have not previously looked into the People Picker with SharePoint apps..

      • Steve Butler says:

        Thanks Bernado,

        Problem now sorted. For anybody else who may hit the same scenario, the call into the user profile service needed to be run with elevated permissions. Now, we’re getting results back out.

        Whilst the claims provider was working natively in the UI and also from PowerShell without the elevation, it was failing in an app instantiation.

      • Bernado says:

        Glad you got the problem sorted Steve! And thanks for posting back the solution :).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s