@saritab2

When you add an implementation class from a different class group, the report definition may not automatically recognize or access data from that class, even if “report on descendant class” is selected. Class group boundaries might affect how data is stored and retrieved.

Can you try doing a test connectivity on the Framework class and its respective implementtion classes to refresh the DB connectivity cache?

if that doesnt resolve, as a workaround, you can try using a Class join to explicitly join the new implementation class using a class join. or Create a simple report definition directly on the new implementation class

@saritab2

usually happens because your framework report was relying on “Report on descendant classes” against one class group/table, and your new implementation class sits in a different class group (different table). Pega won’t auto-union across different class groups, so the query now returns nothing. Fix it like this: first, confirm the report’s Applies To is the FW abstract class and “Report on descendant classes” is enabled; if both implementation classes can share one class group, remap the new class into the same class group/table and re-save the report (best option if your data model allows it). If they must stay in different class groups, create one RD per implementation class (in each concrete class) with identical columns, filters, and sorting; then build a wrapper RD in the FW layer that combines them via sub-reports using UNION (or call both RDs from a data page and merge the results in a post-load data transform). Make sure every reported property is a real column (optimized) in both tables; otherwise the UNION will fail or drop rows. Check that your application stack includes the new ruleset so the FW report sees the new class. Grant Read access (ARO) for the new class and revalidate/save. Finally, clear caches, run the RD with SQL tracer to verify it’s hitting both tables, and, if you use search-backed reports, reindex so the new class is discoverable