Which design pattern to use when modelling something that can contain different properties

I've got a design dilemma.

I have to perform CRUD operations on an entity. Let's call it Report

public class Report 
{
   public Guid Id { get; set;}
   public string Name { get; set;}
   public ReportType ReportType { get; set;}
   //public ?? DetailsTypeSpecific { get; set;} //how to model?

}

A Report can be of a specific type that represents what kind of information is going to inform about.

public enum ReportType 
{
   DownloadsInfo = 1,
   ClicksInfo = 2,
   UploadsInfo 3
}

depending on this type, some reports will contain certain data (in the property DetailsTypeSpecific) and some others will contain other data. For example a Report with type DownloadsInfo will contain things like:

• FileFormat
• IsInCloud
• DownloadedThroughLink

and the reports of type ClicksInfo could have other kind of information. For example:

• UserClicking
• TimesClickedOnSamePage

etc.

A Report will have a button to be exported as an excel file. In other words, a report is excelExportable and I need to provide different implementation for the excel generator depending on the report's type.

Also, the data that the Report contains needs to be added to the Report class as a property, and here's the problem. I don't know how to model it.

Sometimes I will need to retrieve Reports from database, and I need to deserialize its details into an appropriate object.

should I make Report generic where the T represents the type of object it stores?

Should I add a property of type object to the report and somehow have the deserialization/casting as an external functionality

I just know that:

• In the future I want to easily be able to add more ReportTypes and more excel generators for that type
• If I retrieve a specific Report instance, I want to do it in a way that I should not know in advance what kind of Details object it stores

Is there any design pattern that could help me with getting my head around this kind of problems?