Values set in Javascript not saving to server, after upgrade to 9.3.3

  • 1
  • Problem
  • Updated 1 year ago
  • Solved
I have an org in which Skuid was recently updated to 9.3.3

I have a page that, amongst other things, creates some rows in a model and saves them. Some of the values in the fields of that model's rows are calculated in Javascript. This is in a snippet that is called in an action, and another action afterwards saves the model to the server. This worked until the upgrade.

Now, after the upgrade, a number of those calculated field values are not being saved to the server. It seems as if some *are* being saved, but others aren't.

I've started breaking down the page - created a copy, and stripped out the save action. If I look at the model's data in the developer console, it looks as if values are in fact set correctly on the browser side, but are not making it to the server.

Anyone seen anything like this? We've jumped up quite a few versions, so may have been something that happened with a recent, rather than the most recent version.

Any ideas welcome.
Photo of Gary


  • 1,558 Points 1k badge 2x thumb

Posted 3 years ago

  • 1
Photo of Chandra V

Chandra V, Champion

  • 7,580 Points 5k badge 2x thumb
We ran into this problem a few releases ago.  We had an action sequence that looked like this:
- Run a snippet that updates some fields or does xyz
- Save Model (declarative action)

We found the Save Model action was processing before the snippet was done doing it's thing. We fixed this by moving the Save action inside the snippet to control when it was happening.
Photo of Gary


  • 1,558 Points 1k badge 2x thumb
Thanks Chandra, I've actually seen something like that before! But it's not what's happening here. I took out the save action so I could fiddle in the Chrome dev console to make sure the JS is actually setting values correctly. I then called Save on the model - no dice.

Thanks for the reply though, always nice to wake up to a response :)
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,356 Points 10k badge 2x thumb
Hi Chandra -

If the Save model action was firing before the snippet was "complete", then there are two likely explanations:

1) The snippet was doing some type of async processing and not returning a deferred to Skuid so that Skuid would wait until the deferred is rejected/resolved before continuing to the next action.  Did your snippet call any skuid apis - query model, etc.?  Can you provide any details on what the snippet was doing and/or share the snippet?

2) There is a bug in skuid - While possible, I would guess this is unlikely given it would be more widespread since running a snippet, waiting for it to complete before running another action is likely a common use case.

Did you happen to post your issue to the community or Skuid? If this is a bug (again, unlikely), it should be resolved.  Your "solution" to move the save to the snippet itself is a viable workaround in the meantime.

if this is just a matter of using deferred or adjusting your snippet logic, if you can share the snippet, happy to take a look and help get you back to the point where you can use the declarative save.
Photo of Zach McElrath

Zach McElrath, Employee

  • 53,128 Points 50k badge 2x thumb
Gary, a couple of questions, and a probable explanation:

1. What Data Source Type is this Model connected to? Is it a REST Data Source?
2. By "calculated" fields, do you mean "Formula" fields? Are these fields marked "Ui-Only"? 

In Brooklyn, we made a fix to prevent "Ui-Only" Fields from being sent to the server in save payloads. The reason I ask about REST Models is that REST Models allow you to define Formula Fields that are NOT Ui-Only, i.e. fields whose values are computed but will still be sent to the server in save payloads. If you have Formula fields not being sent to the server that are Ui-Only, that would be expected behavior. 


Photo of Gary


  • 1,558 Points 1k badge 2x thumb
Hi Zach!

It's a Salesforce data source, and by "calculated" fields, I mean I'm calculating the value in Javascript, and then setting them on the model with updateRows(). So I don't think this is the problem here.

I'm going to spend some time on debugging this afternoon, I'll let you if I find the answer.

Photo of Barry Schnell

Barry Schnell, Champion

  • 18,356 Points 10k badge 2x thumb
Hi Gary -

A few questions:

1) What version of skuid were you on previously?

2) Does this happen to all users or just some?

3) Have you verified property security to the fields?

4) Any commonalities between the ones that are saving and those that aren't?

5) Can you pull up a standard layout and update/save the values successfully to the fields who's values aren't updating when using Skuid?

6) If you are familiar with the network tab in the browser console, you can view the payload that is actually being sent to the server (XHR).  From there, you can determine if the issue is client side (the values are not in the payload) or server side (the values are in the payload but not being updated).

7) if possible, try creating a test page for the SObject that you are updating setting the condition for the model to the id of the record that you are trying to update.  Put the field that isn't updating on a field editor.  Preview the page and manually set the value of the field and click save.  If you can do this and depending on if it works or doesn't work, it should help drive the rest of the troubleshooting/isolation.

If you can share your snippet, happy to have a look to see if anything stands out.
Photo of Gary


  • 1,558 Points 1k badge 2x thumb
I've managed to fix this problem. Here's the explanation and what I think the cause is.

We have two models on the page that look at the same Salesforce object. On one (let's call it Model 1) I had selected the fields on the Model that I was trying to set in Javascript, and on the other (Model 2), those fields weren't present. However, in the Javascript, I was setting the fields on Model 2.

Which leads me to believe, as this was working in the previous version we had, that at some point, Skuid was looking at the metadata across all the models and filling in the gap on the model where I hadn't selected the fields. But that no longer happens.

Probably pretty low chance of it happening to anyone else I'd imagine, but if you do, I hope this helps!
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,336 Points 10k badge 2x thumb
Hi Gary -

Glad to you were able to identify the problem and root cause, thanks for sharing your findings!

Regarding the metadata, I'm actually surprised that it worked even in previous version.  If I recall correctly, when skuid sends the "save" payload, it iterates the fields registered in the model being saved along with their "changes" to determine what to send.  There is some "shared" storage for metadata, etc. but even with the metadata, since the fields weren't on Model #2, they shouldn't have been "saved" unless there was a defect that has since been fixed in a newer version.

Zach - Any thoughts on what might have been going on in the prior version?  Seems like it's working the way it should in the recent version.  Thanks!
Photo of Chandra V

Chandra V, Champion

  • 7,570 Points 5k badge 2x thumb
Funny enough, same problem came up in my Org on Friday on a page that's been in use for almost a year without issue.  We are on 9.3.1 in that environment.  I was setting a boolean to TRUE in the action framework (not JS) and did not have the boolean in the model.  Prior to Brooklyn, the boolean would still get set and saved.  Users were not getting an error ... the boolean is used to trigger a Salesforce Send email action and the email would just not go out.  Added the boolean to the model, and all is well now.
Photo of Khamla Phimmachack

Khamla Phimmachack, Official Rep

  • 1,946 Points 1k badge 2x thumb
Thanks everyone for your patience and for posting about this issue. It turns out this problem was related to a bug where these changes were not being sent as save requests. This issue has been resolved in the Brooklyn Update 1 - Iteration 2 and Brooklyn - Iteration 6 releases which are now available from the Skuid Releases page.

As a reminder, Salesforce does NOT allow reverting back to prior versions of managed packages. Skuid always recommends installing new versions in a non-business critical sandbox environment to test all mission critical functionality before installing into a production environment. We also recommend that you update out of date themes when you upgrade.

Photo of Hasantha Liyanage

Hasantha Liyanage

  • 1,446 Points 1k badge 2x thumb
Hi There, We have an issue that trying to update and save the model data is not saving to the salesforce end, as I could see updateResults of the saved results array is empty. Please refer to the screen grab attached.

We have a method which could call multiple times, and the method will prepare some data and execute the save action.

Any thoughts? Could this be a Skuid issue? 


Photo of Arne-Per Heurberg

Arne-Per Heurberg

  • 2,756 Points 2k badge 2x thumb
did you ever figure the last out?