Things can go wrong during binding. The property path may be unable to be resolved or an exception may be thrown when getting the value. Perhaps the index or key doesn't exist. In those cases, it can be helpful to have a fallback value defined in your binding expression. These values are provided using the FallbackValuexe "FallbackValue" property.In this example, assuming you have an ApprovalCode field in your object but it throws an exception in the getter (odd, I know) or is otherwise unavailable, the TextBlock will display the value Unavailable. <TextBlock Text="{Binding ApprovalCode, FallbackValue=Unavailable}" /> In many cases, I think it's preferable to have default values and fallbacks defined in your model or view model, especially because that'll make it easier to test. But fallback values in binding can help in a pinch or in cases where you need to handle an exception condition happening between your view model and view.More common than fallback values is custom null value handling.