We can use entity[“<attributeName>”], or we can use entity.GetAttributeValue<T>(“<attributeName>”)
The second option won’t produce an exception if the attribute is missing – it will return null instead. It will also return null if the value of that attribute is, actually, null. This may look all right, but there is a difference. So when does it matter?
Imagine these two scenarios:
In the first scenario, we would query an entity from Dynamics using the OrganizationService, we would ask for a specific attribute, and, then, we would not get it in the result if it’s null. GetAttributeValue would give us null, which is fine since we know how to interpret that result.
In the second scenario, we would have a “Target” entity from the plugin context. However, that entity won’t have any of the attributes that were not submitted from the client. We can still call GetAttributeValue, and it will still return null for such attributes, but we would not be able to say if an attribute just was not provided or if the value was, actually, cleaned up, and “null” is what’s being set (imagine a whole number field which had some value, then the user emptied that field control and hit save). This is when, if you wanted to know exactly what’s happening, it may be better to use Entity.Contains(“<attributeName>”), and, then, compare the value to null (Entity[“<attributeName>”] == null)