If you use Call API as an action to write to a column, I think theoretically you can add an action to clear that column’s values before running the call, and display something until that column is not empty.
When you say display something until that column is not empty. Are you referring to an element on the page itself, or the wait for condition action?
I think another issue I’m experiencing is the delay between adding new rows via the API, and then the relation/query columns updating with links to these new rows. It seems to vary but there’s a 5 to 10 second delay before these relations appear on the screen.
Are you adding rows to a regular table, or a Big Table?
If a Big Table, you can try adding a Reload Query step to your action sequence.
How many mutations are you typically sending? In my experience, Call API is not the best method for adding any more than a handful of rows at a time, because it does take a while and results in a less than optimum user experience. I don’t know it for a fact, but my working theory is that the Call API action waits for a response, and the more mutations you send the longer it takes for the Glide API to process them and return the RowIDs, and so the longer it takes. In cases where I need to send large batches of mutations, I send them as a POST to Make instead, and have Make send them back to Glide. Adding the rows isn’t any faster, but the user experience is much better.
Just getting back to your original question:
What if you just trigger the notification before the Call API action?
The other thing is that you mention relations/queries that depend on the new rows. You could also display a component with a “Loading…” message while those are empty.
It’s a regular table that is hosted in Google Sheets.
As a matter of fact, I currently use Make for the workflow, but the data from Google Sheets is not syncing quickly enough into Glide, which is causing a poor user experience.
Initially, I considered displaying the message while the relation is empty, however, the user may already have added different transaction rows, so the relation is not empty.
Even when adding three rows, the sync to the relation takes a few seconds. It’s not necessarily the speed of the adding of rows that is the issue, the time it takes for the Relation/Query columns to update is unpredictable.
oh, maybe I misunderstood. When you mentioned Google Sheets I thought you meant that you are adding rows to a Google Sheet and then waiting for them to sync to Glide. Is that not the case?
Maybe if you can describe the flow precisely, just so that I’m not addressing the wrong question?
The user fills in the Move Product form and this creates a Transaction Row via Glide Action.
The Glide API is then triggered, that grabs the Serial Numbers from the Transaction record, it then creates a new Transaction record for each of those Serial Numbers.
The original Transaction form row is then deleted.
The relation column then links to the newly created Transactions.
The data table then displays the new records.
The issue causing the visual delay occurs as a result of Step 2 and 4 I’m getting.
hmm, why are you adding a row and then deleting it again?
Why not just use a single row table with User Specific columns?
Just to clarify Step 2 - what you are doing there is a Call API action to https://api.glideapp.io/api/function/mutateTables with a mutation for each row to be added, yes? Typically how many rows are being added with this step?
My gut feeling is that your flow might be more complicated than it needs to be, but it’s a bit difficult to say for sure…
As it’s a Form Container I cannot prevent the form submission. And I use the submit button as the trigger to call the API. It would make more sense if I could prevent the Form Submissions, call the API, and then displays the related Transactions.
Maybe I add a button inside the form that opens a new screen with a separate form/workflow for adding multiple serial numbers and this way I can keep the original workflow.
The API creates a row per serial number. Typically it will be around the 3-5 mark but they could move up to a 100 at a time in some instances. Obviously they would expect delays in those cases.
I’m going to play around with my idea above and see if that improves the user experience.
mmm, I’d recommend using a single row helper table to drive the screen. Fill it with user specific columns, and instead of using a form (which will always add a row), just use a normal details screen and add whichever input components are required.
