Yep - makes sense. I’ve done similar things using the API. It’s functional, but not ideal.
This is where I climb up onto my soapbox and shout about the deeper responsibility that Airtable has to create an open design. In the realm of sharing information, the requirements are clear:
- Users should be able to share data in arbitrary ways in the immediate context of selected data.
- Recipients of shared data must include named Airtable users, non-users, and other services.
- Recipients of shared data must know precisely who (or what process) sent the data.
- Recipients of shared data must be able to reply regardless of recipient class (i.e., human, machine, user, non-user, etc.)
I’m not suggesting Airtable must build this - I’m simply saying (as @RnJ has said) that #3 is a key requirement if you promote your tool as a workflow solution. Airtable makes this claim, of course, so they have opened this door and users expect the doorway to lead toward a viable workflow outcome.
What Airtable must build (IMHO) is the capacity to meet these requirements. Ergo, a design that is open enough to instrument all of these requirements including #1 which I believe is one of the more important requirements. Airtable + Zapier rule in #2,3,4 but rule out #1.
ps - There’s an unstated #5 in this requirements list (sharing in a security context) but that’s for another time.