Unfortunately, the scripts associated with automations are even more limited than the regular scripts. I need to be able to query the user and that is not available. I’m basically trying to create a streamlined data entry system. I’m entering data in both the main record and creating linked records but most of the time only need a couple of pieces of data from the user and the rest can be determined programatically. I was hoping to do this in airtable but it will probably have to be done using airtable’s main api.
The biggest things that I see missing are that from a script associated with an automation you can’t get user input with calls such as input.textAsync that you can with a scripting app. In addition I can’t figure out a way to fire off a scripting app from a mobile device. Maybe I’m just missing something obvious.
That’s an interesting approach and will give it a try. I have found forms to be pretty clunky and I might just be able to use a view to achieve the same thing. From a database design perspective the thought of having to create a table just to do data entry into another table does not sound good. I would also need to delete the record right away to make sure I don’t have any more denormalized data laying around than absolutely necessary.
The entire point of automated processes is to remove human dependencies. By definition, an automation process that depends on human interaction is not automated.
Airtable actions were created with express objective that they work without interruption. What you are describing is a workflow, not an automation process.
Yes, I agree. I’m trying to develop an efficient workflow. I’m using airtable to help manage a farm. Right now using basic airtable functionality it requires scanning a QR code, 7-8 taps and entering data into 4 fields to record a harvest event. This process is repeated 50-100 times twice a week so speeding it up can increase productivity quite a bit. For a vast majority of the time all that is needed is the scan of the QR code and entering data into one field. The rest can be determined programatically. Default values for date fields and single select fields would help a great deal. I tried doing that part with automations but the lag time is so long that it defeats the purpose of trying to reduce the time for data entry. If I could have a button that could call a scripting app on a mobile device I could probably do what I want to but that isn’t supported at this time. The only reason I was trying to coerce automations was that it was the only tool I could think of other than to roll my own from a React app that is running other parts of the farm. I hope this makes some sense.
I guess this gets back to my original question which I didn’t explain well. I need to execute a scripting app from a mobile device to be able to streamline my workflow. As Bill correctly pointed out automations are not the correct tool to use. I hope that when scripting exits beta and goes into production it will be possible to execute a scripting app from a mobile device the same way you can from the desktop version. I will add this to the request list. Thank you both for your help in this matter.
Scripting has been out of beta for over a year. While its features have grown over the past year, none of the feature additions have been anywhere near the scale of what would be required in order to run a script on a mobile device.
You may want to look into a portal such as Stacker or miniExtensions for adding/editing records from a webpage.
I can think of a number of reasons this is not an ideal approach. The biggest is nature of mobile apps; they must ensure security in a climate with many more attack surfaces than a desktop browser must endure. As such, any kind of scripting is likely to raise a number of challenges that are easily overcome in a non-mobile-based web browser.
Another challenge is script running at the edge. While desktops typically have lots of memory for performing dynamic [late binding] processes, mobile devices are limited and constrained in ways the desktop is not.
Lastly, connectedness. Mobile devices are typically not in the most favored connected devices and this could put added pressure on server-side data requests and updates. Imagine a script process designed to expect an always-stable connection and what would happen with just a few timeouts because the connection cannot be sustained. You’d likely have to write the script one way for desktop browser and completely different with error and completion-handling logic differently for the mobile app. Should Airtable endure the likely support obligations, training, script examples and primitives to make this possible? I think it’s a risky idea if the goal is profitiability.
Ergo, my feeling is that you will never see dynamic (lately bound) script-building or script-running features in Airtable’s mobile app.
As I mentioned earlier in this thread, execution of any manual or automated process based on custom scripts should be performed through indirection - i.e., establish conditions for said custom actions to fire and allow the servers to perform these processes because - well - that’s what they do well and the infrastructure is already in place.