Reached limit of 50 requests per script invocation. Best way to go around this?

I don’t know JavaScript so I can’t help you with your scripting question.

However, to answer your question about Zapier, I highly recommend NOT using Zapier by using Make instead.

Make is significantly cheaper than Zapier, and it is also a zillion trillion times more powerful than Zapier. I regularly switch my clients from Zapier to Make, and they’re blown away at what they can FINALLY do that they were never able to do with Zapier. Make can do things that Zapier can only dream of doing.

The major downside with Make is that there is a very steep learning curve to understanding the product, but once you understand it, you will be sailing high! :sailboat: :smiling_face_with_sunglasses:

p.s. For companies that have a budget to hire an expert Airtable/Make consultant, I’m also available to help people with their Make scenarios.

Ha, I think we’re going to need to define “best” here my dude

I feel like “Best” in terms of your time spent would probably be the +33 runs / week thing as you’d be able to get that done in 5 minutes.

How many of the available 50k automation runs are you using on average per month? If you’ve got a lot of spare runs I’d just do this I think

There are various alternatives.

Are you limited to using an automation script? If you use Scripting extension, there is no limit on the number of requests per script. You will need a human to push the button to run the script, but you might be able to tie the button push in with a different workflow.

How many other automattions are you using per month? 33+ automations per week is a fraction of the 50,000 automation runs a pro workspace gets per month. This will probably be the easiest to scale.

Since you are concerned with maintenance once you leave the project, I recommend staying inside Airtable. Even if you have to split the script into two with some code duplication, it will be easier for someone else to understand what is going on if there is only one platform/login to deal with.

Even if you break this into two separate scripts, it hits the ceiling at 51 classes, right?

I think @kuovonne is on the right track -

Automations are ideal for eliminating human actions for repeating and often time-centric processes. I don’t think this falls into that ideal use of automations. Correct me if I’m missing something, but these processes are intended to run once for a given week and ideally you (the maintainer) needn’t worry about them. However, wouldn’t it be easier to run a single script extension once a semester, or once per year?

I get it - you want to get humans out of the business of managing processes, but this could be an aggregate process that could easily scale to thousands of classes and may actually benefit from a human task to configure a giant swath of forms.

Correct me if I’m missing something, but these processes are intended to run once for a given week and ideally you (the maintainer) needn’t worry about them. However, wouldn’t it be easier to run a single script extension once a semester, or once per year?

This is an interesting idea :bulb: . Adding certain prompts to the form generation process would perhaps help maintenance so the script would not have to be manually adjusted if title or other things were to change. So that would justify a manual action.

I’ll keep the workflow to be generated on weekly basis for now. That approach has some potential benefits as well, as the form can react to some data changes during the year (changes in teachers and such) so it feels safe for that reason.

But even a button push on weekly basis isn’t really a bad thing if it allows some extra configuration. Thank a lot @Bill.French and @kuovonne :thumbs_up: I’m seeing some nice paths forward now.