and yet the related object got the application amount properly, and likely got the billing Id properly as well – so why when it saves it gets confused from adopting rows?

Mark,

I have a few questions to start looking into this:
1. I am assuming that Billing__c is a reference field. Is that correct?
2. Are you familiar with finding the actual SOQL in the developer console? (If so, we might want to look at that to see what is actually being sent)
3. Where is the Id being set for the rows you are adopting? I have a feeling its getting a “Skuid temporary Id” which SFDC will not know what to do with…

Thanks!

Thanks Clark,

The object that throws the error is the Incoming Payment Application which references the Billing (invalid reference Id for Billing)

Not sure about the SOQL

The reference is to a SKUID temporary ID, but inserting with temporary Ids seems to work properly when not using “adopt rows from model”, only when I started using this adopt rows approach did I start seeing this error.

Okay, I have a couple additional ideas:

#1:
You may have to have 2 separate save actions. The first save action would need to save the “New_Available_Billings” Model. The second save action should save the “New_Incoming_Payment_Applications” Model. 

The Billing Record has to be created before we can save the payment application.

#2 (longshot, but have to ask):
Are there any conditions on the “Billing__c” field on the payment applications model?

Thanks Clark,

In response to 1, why would it error in this case if the rows are adopted vs. the rows not being adopted?

There are no conditions on the Billing field.

I found another way of achieving what I’m looking to do, but this still seems like a strange error in relation to inserting related objects (related by SKUID IDs) when adopting rows from one model to another.

I will see if I can get a clear description of why this is the case. I have a general sense of why I think it works this way, but let me verify.

The adopt rows actions are super powerful, but also fairly complex behind the scenes (from what I understand). So I would hate to misspeak on the topic.

Thanks!

I’ve found a workaround for this utilizing a javascript snippet.

The snippet will iterate over rows in a source model and create rows in a destination model. It will also reference a “parent model” for the Id to relate to.

var params = argumentsu0],

$ = skuid.$;

//Source Model containing rows we’ll iterate over

var sourceModel = skuid.model.getModel(‘SourceModelName’);

//Destination Model to create new rows in

var destModel = skuid.model.getModel(‘DestModelName’);

//Model containing our parent object that we’ll get the ID from to associate our newly created rows with

var parentModel = skuid.model.getModel(‘ParentModelName’);

var parentRow = parentModel.getFirstRow();

var parentId = parentModel.getFieldValue(parentRow,‘Id’);

//Remove all rows from destModel

destModel.abandonAllRows();

$.each(sourceModel.data,function(i,row){

    var cRow = destModel.createRow({doAppend: true});

    destModel.updateRow(cRow,{

       DestField1__c: sourceModel.getFieldValue(row,‘FieldName’,true),

       DestField2__c: parentId

   });

});