Limitations of the people picker field
The people picker field in a Sharepoint list is a useful tool: it allows users to sign up for say, a membership list, by simply starting to type their last name and selecting from a drop down of “suggestions” supplied by the the user profile service. The people field contains an array of user information including profile picture, email address, department etc. but you have to choose which option you want to display when you create the field. A common problem is that once you’ve defined the type of output for the field – “name with picture and details”, for example – you can’t then use the field to also display another value, such as the user’s email address or employee id.
So if a client asks for additional information to display in a separate field after you’ve created the column, it can’t be done – without adding another people picker column which is not efficient or practical. It’s a frustrating design because Sharepoint is querying all the data, but you can only include one format of that data in a view.
The challenge – populate a field based on another field’s value
I recently bumped into this limitation after creating a simple app that allows users to send each other ecards. The app comprises a list, a selection of different card designs and a workflow that sends out the ecards. The workflow gets the email addresses of the recipient and the sender (from the “created by” field) fine, but now I was being asked to add an option that would automatically email the recipient’s manager, if the sender requested it.
So essentially what I was tasked with was figuring out how to dynamically populate a field based on a value in another field. In Sharepoint, that’s the stuff of nightmares!
The solution – workflow logic
For this app, I was focused on getting the manager’s email address using the “recipient” people picker field, but the underlying process can be adapted to display any additional, available data from any people field in the list – employee id, picture, department etc. So for instance if you want to show a user’s picture and details in one field and email address in another, you can do it with this process using only one people picker field as a data source.
For the manager details, Msft provides an action in Sharepoint 2010 workflows that can look up a user’s manager – the “Find manager of …” action. The logic needed for this part of the workflow then was:
- If the sender selects the “email manager” box
- Look up the manager of the recipient and return it as a variable
- Update the “manager” field with manager’s email address
- Wait for that update to happen, then…continue the workflow.
Assuming the workflow does its job, I’d then have all the email addresses needed to include the recipient, sender – and manager (if applicable) in the “to” and “cc” boxes within the email editor.
The solution – step by step
So to get started, I added to the list 2 new columns: a boolean yes/no field (to trigger the manager look up action) and a people picker field to house the workflow generated manager’s email address. (I hid the manager field so it wouldn’t show up in the form view by activating content type options on the list).
The existing workflow was adapted to include the above logic, as you can see here:
- Condition – if current item field = value
- Action – Find manager of current item field (recipient) and create a variable
- Action – update “manager” field with variable (formatted as string)
- Action – wait for manager field to update
- Then continue the workflow – adding conditions/actions based on card design selected and populating the email address fields, email body etc.
As a rule I dislike editing existing workflows because they never seem to work after you tinker with them. In general, if you delete something, make sure you don’t leave any extra lines between the workflow’s elements. And make sure conditional rules don’t bleed into each other!
it’s also worth noting the data formatting of the values returned has to be right. There are little drop downs that show the options when configuring this which are easily missed. The manager variable should be returned as a string to ensure all the people details are available in the manager field, but when you add the manager field to the email it should (obviously) be returned as an email address.