PROBLEM: While trying to adopt a row from one model into another, we found we couldn’t save the adopted row as a new record.
RESOLUTION: Instead of adopting an existing row, create a new row in the destination model and populate its fields with data from the source row using merge variables.
The page was set up with a model that queries custom settings
- An action sequence had been set up to adopt a row from the custom settings model ( the source model) into another model (the destination model).
- The destination model was connected to a different Salesforce object -- not custom settings.
Since custom settings are different from normal Salesforce objects we wondered if this meant Skuid wouldn’t be able to interact with custom settings. To answer this, we built a simple page
- in our test org and set up some custom settings for it to query. We found that users were able to do full create, read, update, delete (CRUD) operations on the custom settings via a Skuid model.
- Next we tested whether or not a row on a custom settings model could be adopted into another model. We added a model on the Account object and were able to use the Adopt rows into model action to adopt the custom setting row into the account model.
Though we could adopt the row, we then observed that we couldn’t save the Account model. Using the skuid.debug.modelMap
- () console command at runtime, we noticed that—despite adopting the row—there were no ‘changes’ listed in the Account model. That explained why saving the model didn’t commit the adopted row to Salesforce, but we were unsure why this didn't register as a "change" in the model.
- We tested the Adopt rows into model action between two standard Salesforce objects to check again if there was something unusual about the custom settings object that could be causing trouble. However, we saw the same behavior as in step 3 above.
- Ultimately, we were able to confirm with the product team that when a row is adopted into another model, it’s treated as though it was queried by that model -- not as a new record. So, what we were seeing is intended behavior.
Instead of using Adopt rows into model, we were able to use the Create new rows action to make a new row in our account model, with data populated from a selected custom settings row (which users would select via a table row action).
Using Adopt rows into model is useful for page-level logic, but does not create new, savable data rows. Instead, leverage the Create new rows action whenever new rows should be created. Use context to pull data from a source row and merge variables to reference that data in the new row’s fields.
Get help with an issue
Ask in the Skuid user community in the questions category
If you have paid support ask your question on our support portal skuid.freshdesk.com
- If you’re interested in support, contact your Account Executive.