I started looking into this issue once a few customers had reported it and wanted to see if there was a solution, so what was the problem? Well, adding these 2 fields to a custom form in the portal requires you to put the property name on the portal form. The property name is the target name of the relationship in this case.
However, the target name for the RequestedByUser and CreatedByUser relationships are identical, which is down to Microsoft for coding it like this…
A custom type projection is needed for the portal form to load in both relationships as there is not a type projection out of the box that includes RequestedByUser. But when you use the custom type projection the portal brings back 2 identical target Ids for ‘CreatedWorkItem‘, one for CreatedByUser and one for RequestedByUser. The custom portal form does not understand which one to use and fails.
We came up with a solution to get the best of both worlds having both relationships as user pickers displayed on the work item form.
We started by displaying the CreatedByUser field using the default type projection as this works normally as expected. To include the RequestedByUser field, we built a custom type projection which only included the RequestedByUser relationship and imported this management pack into SCSM.
Then we added a user picker onto the custom form with a dummy property name to populate a field on the form to work with.
For more information on this solution, please use this Community page link.
Many thanks to John Doyle and Justin Workman for their help!