You could use a table with a drawer where the drawer displays the reclassification records or you could create a new object called “unifiedbillingtable” that is the child of billing and has a lookup relationship to reclassification. Then have salesforce process builder processes create a new unifiedbillingtable record each time a billing or reclassification record is created. Have it populate whatever fields you want to display in your table. Then you can build a table on the unifiedbillingtable.

The unified billing object is my thought as well as a way to do this, but is there a way without needing to create a ‘duplicate’ of everything  that is easier to query in the system? Is there some way to merge the objects at the UI level?

The drawer solution doesn’t really put them into the same table correct? Can the information be summarized and If I were to export the table, would it be able to come up with a CSV of rows all together?

With a drawer the data would be in separate tables and not exportable into a single CSV. Skuid was working on the ability to merge two objects into a single component, but I’m not sure if they ever did. Maybe in the newer releases. You could use formula fields in your unifiedbillingtable object that reference info from the billing and reclassification objects. Then your process builder would only have to add the billing ID and the reclassification ID. That should minimize data duplication.

Mark, if you are doing a “read-only” scenario here, where users don’t need to edit the data in the table, then one way that you can do this is to create a Ui-Only “Union” model, and then use the “Adopt Rows” action to take rows from each of the two “source” Models and adopt them into the “Union” Model. Then, have your table display data from the Union Model only.

You would need to create fields in the “Union” Model that are common to both of the source models, e.g. if both Models contain an “Alpha” and “Beta” field in common, create those two fields on the Union Model. 

The main trick here is the timing of running the “Adopt Rows” Action to populate the Union Model with data from the two (or more!) source Models. If there’s no way that the data in either of the two source models could be re-queried by users (e.g. via Filters / Search), then the simplest way to achieve this would be the following:

1. Un-check the “Load model data on page load” property on both of the two Source Models.
2. Create an Event-triggered Action Sequence which is triggered on the “Skuid Page: Rendered” Event, which queries both of the Source Models (in a single “Query Models” action) and then runs two “Adopt Rows” actions, to adopt rows from Source Model A into the Union Model, and then to adopt rows from Source Model B into the Union Model.

Skuid’s Adopt Rows action doesn’t allow you to map field names from the source model to the target model, so your source model field names (e.g. Alpha and Beta) must be exactly the same as the field names in the Union Model in order for this to work using the approach as described above. If the source/target model field names are not identical, then you’d need to, instead of using the “Adopt Rows” actions declaratively in the Action Sequence, write a custom JavaScript Snippet that does the adopt rows functionality, and run that snippet from the Action Sequence . In the snippet, you could perform any custom source -> target field name mappings. Here’s an example of what such a snippet would look like:

var sourceModelA = skuid.model.getModel(“SourceModelA”);
var sourceModelB = skuid.model.getModel(“SourceModelB”);
var targetModel = skuid.model.getModel(“UnionModel”);
var newRowsFromA = sourceModelA.getRows().map(function(sourceRow) {
    return {
         Alpha: sourceRow.Some_Field__c,
         Beta: sourceRow.Another_Field__c,
    };
});
var newRowsFromB = sourceModelB.getRows().map(function(sourceRow) {
    return {
         Alpha: sourceRow.Something_Else__c,
         Beta: sourceRow.YetAnotherField__c,
    };
});


targetModel.adoptRows(
   newRowsFromA.concat(newRowsFromB)
);

Thanks Zach! Did an initial test on this and it seems to do exactly what we’re looking for.