Skip to main content

I’m setting up my landscape company in Airtable and one major aspect is scheduling subcontractors and collecting data from them in the field. I have a central Base in my Pro workspace that is handling everything from job intake to billing. I want my crews in the field to be able to use the Airtable app to get their daily assigned projects and enter data about what they do that can be used to calculate payroll and billing info. A popular topic around here is the lack of granular sharing permissions and this is something I’m trying to do a workaround for. While data security is a concern, I also don’t want to pay for a license for every crew to use the Pro workspace base and I think that the simplicity of having their own base with only their schedule in it would be a lot easier for them to use. It also gives them a history of what they have done so they can make sure they get paid accordingly and they don’t see what the other subs are doing.

Idea: Create free bases for each subcontractor or each crew in a separate workspace. Create a Zap with logic that will send job instructions along with the original record ID to the subs’ bases from the main base when they are assigned a job. When a job is filled out and clicked as complete in the free base it would trigger a Zap that would update the main base (using the original record ID) with the job data.
**Question:**If I had to create up to 15 auxiliary bases would this web of Zaps be reliable enough or is this just asking for missing data and tracking down failed connections? The update Zaps would run throughout the day and probably not at the same time. The assignment Zaps would run at the same time, maybe as many as 15 at a time(10 fields of data).

I’m moving from smartsheet where I got burned trying to rely on Azuqua to transfer data between sheets so I’m nervous to move forward with what feels like an elaborate workaround that depends on Zapier.

Thanks,
Ross

Hi Ross, and welcome to the Airtable community!

My hunch is that Zapier (and certainly) Integromat are up to this challenge. However, two pieces of advice I might toss out.

  1. Size the workflow to determine a general estimate of the cost for these tools if it turns out they work, then multiply by 3 (to make it conservative and meet future scale).

  2. Create the complete configuration for just one subcontractor and test the crap out of it for a month to validate that it really works.

I build complex integrations for a living and there is no shortage of businesses that have tried no-code app adhesives like Zapier, and found that they were either too brittle, or too costly. There are many other issues that can impact your architecture and decision to press on.

And to be fair, for every poor outcome I see, there are probably hundreds (maybe thousands) of very successful Zapier/Integromat integration processes that are reliable, sustainable, and cost-effective.

Much of this success (or failure) is closely related to the complexity of the overall solution and that is often gated by the data model and other design choices you make concerning the information architecture.

Lots and of moving parts tend to exponentiate the likelihood you will encounter integration issues.

Hi @Ross_Collins, we’ve done several implementations similar to what you describe, but that being said, they are complex and I agree with @Bill.French - it can get tough to manage very quickly if you don’t set it up correctly. So, I only recommend it if there is a very specific reason for it and you understand the consequences of it.

If you do want to attempt it, you’ll likely require our advanced zapier connector (On2Air: Actions)

Thank y’all for the input. I agree that there are too many things to maintain especially at scale. Too many bases and too many connections to fix or modify down the road. I’ve changed my mind and I’m testing a more simple and scalable solution, the prefilled form that updates a row trick. I created a formula that prefills a form in a dummy base with the original record ID. I then share a read only view that includes the formula field with the link. Then the user enters their info into the form and the new record in the dummy base triggers a zap that goes back and updates the real record. I think this solves all of my problems and this would scale to as many people as I want to assign work to and I only have one zap and one base that I deal with a a dumpster base that will keep the info in case my zap fails.

Have y’all had success with this approach? .

Thank y’all for the input. I agree that there are too many things to maintain especially at scale. Too many bases and too many connections to fix or modify down the road. I’ve changed my mind and I’m testing a more simple and scalable solution, the prefilled form that updates a row trick. I created a formula that prefills a form in a dummy base with the original record ID. I then share a read only view that includes the formula field with the link. Then the user enters their info into the form and the new record in the dummy base triggers a zap that goes back and updates the real record. I think this solves all of my problems and this would scale to as many people as I want to assign work to and I only have one zap and one base that I deal with a a dumpster base that will keep the info in case my zap fails.

Have y’all had success with this approach? .


That is one approach. We used to do things that way. Now, we utilize Jotform -> Zapier -> Update Airtable. This approach adds flexibility and doesn’t require an extra table in Airtable for the form updates.

That was one of the reasons we built our other product (On2Air: Forms)

Terms & ConditionsAccessibility statement