Forcing computation refresh?

This question sits at boundary of bug & how-to: is there a mechanism, within a glide app, to force a re-fresh / re-compute of the columns in a Glide data sheet? The issue that I observe is that in certain critical circumstances, computed columns (e.g., math columns) do not update with sufficient timeliness during custom actions triggered by a form entry, and this causes ‘blank’ data to be passed causing bugs. Here’s a specific use-case example:

The use case starts with the user entering information for a new calendar event in a Glide form. This data then populates a Glide data table–no issues–and my Glide data table is then meant to compute a few items from this data (e.g., Unix Timestamp), also no issues. For the desired user experience, as part of a custom action triggered by form submission, Glide should pass along certain data to a web hook. So, user enters calendar info for an event. Glide then computes a few items from this data… and then Glide app is to pass that information to a web hook to invoke an external SMS service (Integromat–>JSON–>ClickSend).

Here’s the trouble: in execution on a Glide phone app, the computed data (in this example, Unix time stamp computation) does not get passed to the web hook–it’s just left blank. The rest of the use case and data flow (and JSON/Integromat/ClickSend) work correctly. The missing data seems to occur because the computed (Unix time) column doesn’t update quickly enough on form submission.

Is it possible, within the form-triggered custom action, to force Glide to update a table’s computed columns so that the app passes along a complete set of data?

All constructive suggestions welcome!!


I think what’s happening is that the actions fire too quickly. The row is added at almost the same time that the webhook is fired, so the computation hasn’t happened yet as the webhook fires.

Unfortunately we don’t have any way to insert a delay between actions, or slow them down.

What I would do is dump the form idea and create a custom form instead, from a details screen, that fills user specific columns as they are being populated. Then create a math column that calculates your unix date from that user specific column. This will do the calculation right after the date is selected. Then you can add a submit button that adds the row from those user specific columns, fires your webhook, then clears out the user specific columns so they are ready for the next form entry. Finally put in a Go Back action to go back to your previous screen.


Thanks Jeff!

It took me some days to implement, but in the end your suggestions were spot on–thanks much. The user-specific column solution is a critical piece and the fact that computations related to these are executed more quickly is something that more users / developers might benefit from knowing.

One follow up question, and that’s concerning ‘required’ elements in forms. The typical Glide form allows for this–the user must provide a response if they are to submit the form. Using the custom form (built from a details screen) doesn’t seem to allow for this. Any suggestions?

Thanks so much…!

Using the custom form, I assume you have a button that utilizes an “Add row” action. If you need the user to provide a response to some certain fields, don’t show the button (using visibility conditions) until those fields are not empty.

Another good practice is to clear those fields after the add row module using set columns.

1 Like

In addition to @ThinhDinh’s idea, sometimes I’ll show the button, but use a custom action with If Then logic to show a notification if some fields are empty, instead of adding the row.

1 Like

This is what I do…

Each one of the conditions in that if-then-else represents one of the “required” fields in my form.
I much prefer this approach as it keeps most of the logic in my Glide tables. And the visibility condition for my Submit button is very simple (and intuitive): “show component when ite-can-save-note is true”