Usually, any kind of "conditional" display logic that is applied to a row in RadGrid is applied during the OnItemDataBound event. This event fires immediately after the row has been bound to its data and gives you the access you need to modify/update row cells based on your business logic.
That said, the kind of logic we're talking about there is usually "display logic"- such as colors, font weight, etc. It sounds like you may need to conditionally bind cells to a different data field?
If that is the case, things become a bit trickier if you need to support data editing. A grid expects that all values in a column relate to the same data field, and while these values can easily be "overridden" in read-only scenarios, keeping data accurate during editing becomes more challenging. Same is true for filtering and sorting. A single column expects to sort/filter against a single field in the data source.
For situations like this in the past, I've usually had the most success "combining" my similar data values in to a single "view" at the data source level. If you have access to the SQL, this can be done using Views in SQL Server. If you only have access to your service, this can be done in memory by building a new DataTable. By consolidating the data there, then binding it to your RadGrid, all operations like sorting and filtering remain simple.
Does that make sense? Let me know if you have questions with that approach and I'll be happy to elaborate.