I like the send record function (select records - right click - send record), however it would be nice if you can send from your email (instead of the default noreply@airtable.com) so people can respond to the email.
There are some real devils in any design that uses SMTP (email) to send on behalf of another party. I won’t go into the myriad security issues, but this exposes all sorts of problems. As such, it’s not likely Airtable will endeavor to add a feature like this.
One way to do this (I believe) is Zapier or Integromat. It won’t be so seamless, but I think it’ll get the job done. If I’m incorrect in assuming these two services can accept and forward replies, you are left creating an API process that runs within the context of an email account/server that you fully control.
Zapier offers this for sure. In its own email component you can specify “from name” and “reply to” values or use one of the apps noted in the s/s below to actually send from your own email address:
@Bill.French - good point - no, not the same “right-click” process.
In Zapier, you can trigger by a new record or new record in a view. My suggestion would be to trigger it based on “new record in view” as this way you have more control over the sending process. When there isn’t an inherent data element that can be used to push a record into a view (and, hence, trigger the Zap), I tend to create one specifically for this purpose. Example would be to create a checkbox name “Send email” then have the Zap view based on whether this checkbox is checked or not. Checking the checkbox (too many “checks”…) puts the record in the view and away you go.
Some work to set up, but arguably, once this is done, the email triggering process is much simpler. No right-click, just check the checkbox.
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.
