Hi @max.baumann07. In the situation where one part has some other part derived into it, we have no way to 'include' the 'other' part's material in that derive process. So, we may be able to dig down into the other part to figure out what material it was set to, and we may be able to find that same material in the current part's Materials (or a Material library) then set the current part to that material, but that setting would be 'static'. Meaning, if the other part's material changes, this current part's material will not automatically change too. You would have to use this code process each time, and there may not be any notification about the material change to let you know that this parts material needs to change.
While a part is actively open on your screen, if you open the Event Triggers dialog to the 'This Document' tab, there is an event listed there named "Material Change". In the 'other' part, you could have an iLogic rule listed under that event, that will run when that event happens to that part. However, that other part has no idea that it has been derived into another part, because there is nothing on the side of that part to indicate that (no link or reference). So, you would have to take note of the full file name of the part that it is being derived into, so that you can find it, and update its Material to be the same as that other part, when that event happens. It's fairly complicated.
Edit: If the 'other' part was designed as a Sheet Metal part, and the current part that it was derived into was also, then there is a setting in the derive process to link the sheet metal style / rule. Not sure if using that would cause the current part's material to change when the other part's material changes, but you could try that.
Wesley Crihfield

(Not an Autodesk Employee)