Because Item Updated is asynchronous, the user may not see their new values when they see the list after submitting the edit.
(no updates required since you are changing the value before it gets saved) I would verify that your Event Receiver is attached to the list.
From the results it turns out that when getting the value of a user field from After Properties in Item Adding and Item Updating events the value is different when using the New and Edit form from the value when adding and updating the field pragmatically.
I’ve done some testing and the results are presented in this post. The test is performed when adding/changing/deleting the item’s user field using the UI (New and Edit form) and when adding/changing/deleting the field pragmatically.This is what we have for lists: For both lists and libraries: No value means that column value in the hash table was not available.New value means that the correct value for the column was available. Here is the example: This is a pretty useful discovery. An advantage of using Item Updating to set field values is that the values will be visible to the user after they submit their changes in a non-datasheet view.I always forget this and when I come to create a new Share Point Event Receiver I wonder why the Before Properties or After Properties are sometimes not populated. The Synergy MOSS blog has a really good post describing exactly what properties will contain a hash table and which will be empty depending on which list type the event is coming from and in which method (e.g. I had them flipping back and forth depending whether they were multi-select lookups, single lookups, or plain text/number fields. However, it seems to be the case that not all fields on an item follow the same rules.When accessing a user field in event receivers there are few differences in the returned values when Classic mode authentication is used from the value when Claims based authentication is used.The difference is present in After Properties of Item Adding and Item Updating event.