I plan to use Airtable to record order information from my website. These records will be used to build the product that the customer ordered. These products are custom.
I would like to be able to have the page designer automatically to output a PDF to the attachment field. I would also email this PDF as part of the customer order process workflow for our company.
I like this idea as well. However, there are some issues trying to get there.
The current attachments feature requires the documents “uploaded” are hosted openly on the internet. As such, a block (like page designer) would have to first “crossload?” the document to another server (or Airtable server instance) where the attachment feature could connect to it and make a copy. Just making any Page Designer document public on the Interwebs comes with a number of customer issues.
Ideally, the block would have direct access to the database and simply use the API straightway to push the PDF into the record as an attachment. Of course, Custom Blocks already have this latitude, but, the API supports only the submission of an attachment URL; it doesn’t provide the primitives necessary to directly post a multi-part document into an attachment record.
No Through Streets (purely my opinion)
This is a good example of an API built with many cul-de-sacs; there are no through streets to make this happen easily for custom block developers. It’s also why all companies should consider building their products on top of their own API instead of adding the API as an afterthought. APIs should ideally be foundational, not features to everyone except the Airtable engineers.
Today’s Remedy (one of many possible workarounds)
Send the PDF to a Gmail account as an attachment.
Use Google Apps Script to harvest Page Designer messages, tease out of the message the document, save it to drive.
Post the (openly public) URL into the attachment field, and then delete the openly public page designer PDF from Google Drive.
Most important functionality that we need is the ability to automatically generate a PDF from the Page Designer Block, and then email that PDF to an email address in our record.
We can use our own email app on our own devices — the Airtable Team doesn’t need to worry about building in an entire email interface into Airtable.
We just need the PDF generated and then attached to an outgoing email with the email address already typed in.
This email address will be taken from our Airtable record.
And the PDF will be archived in the Attachment Field.
We simply need the ability to click on a button, and have a PDF generated and then attached to an outgoing email with the email address already typed in.
I’m pretty sure there are some issues with the idea that you can use your own email app because Airtable cannot inject anything into your email app without (a) authority, and (b) a scripting linkage of some sort.
The email server is what’s in question with this comment. When you say “outgoing email” - outgoing from who’s email domain sever exactly?
You can already click on an email address in an email field and it will open up an outgoing email in your email application, already addressed to that person.
This just needs to be extended to attachments.
For example, FileMaker can attach attachments into an outgoing email with no extra authority granted to it at all.
Precisely - it’s simply using the mailto: protocol to launch your own client and it could pass file attachments in that process if the [mailto] URL were instrumented to do that. FileMaker does support this if – AND ONLY IF – the user’s email client supports full command line processing of the mailto: protocol.
As such… [I believe] if you instrument a link (or button) in Airtable to include a format like this - it will work just as it works in FileMaker notwithstanding the other email client support for this more automated approach to generating emails with subject, body, and even documents attached. Airtable needn’t add any new features or provide an email server infrastructure to do this.
Note that in most email clients, mailto: URLs must be URL-encoded, and any attachments must be specified as openly accessible URLs (Airtable supports this, of course). Furthermore, the email client running locally (or a web-based email client) must support full command-line arguments for the mailto: protocol.
Depending on your email client, this format will also work…
Here’s a screenshot of how you set this up in FileMaker. “It just works.” Would be great to see something as simple as this implemented in the new button field of Airtable! :slightly_smiling_face:
The other option is “SMTP Server”. The screen looks 100% identical to the screenshot above, except one additional button appears that you can click on to specify your authentication information for your SMTP server.
