Hi
We have more and more use case where we need to pass PDF file:
Hey @Nicolas -
We have a scheduled engineering investigation into supporting specifically ingestion of PDFs planned for later this quarter, with that to drive some more engineering work early next year to address this need.
The plan is to investigate specifically what would be required for integration with the following systems, are there others we should include?
Pete
Hi Pete, thank for the quick feedback.
For pdf in connector function INPUT: the use case is for logistic. When they unpack receiving, they scan a lot of legal document and store it in pdf (with multiple sheet, image file is not recommand, pdf is better). In Tulip, they select the correct pdf in windows file system and send it to SAP as attachment of SAP Inbound delivery.
For pdf in connector function OUTPUT: the use case is integrated with:
Nicolas
@Pete_Hartnett I’m interested in the ability to use File type Input in a connector as well.
I have a documentation table that stores many PDF records. I currently populate each field in the table via individual trigger actions in apps. This causes issues when trying to implement a Table Record Added automation as the record shows created as soon as the ID is created thus causing the automation to run before the remaining fields are populated.
In other tables (that don’t have PDFs) I have created connectors that populate all fields simultaneously thus allowing my Tulip Automations to run as expected.
It appears I’m unable to do this same workaround when a File type field is involved. It seems I can’t pass a File from the app to the table via a connector input. I know I could pass it as a url, maybe even as a signed url, but that doesn’t seem like it would work as I would expect.
ps. of course the alternate solution is building in a delay in Table Record Added automations to allow time for the app to populate the remaining fields, but it doesn’t seem like I can do that either.
Hey @doneil -
A couple thoughts here - recently we added the ability to trigger automations only when specific fields are updated, making it easier to wait for all fields to be filled before automations run (as well as reducing unnecessary runs if the update is irrelevant to the automation).
This isn’t quite what you are calling out (waiting for all fields to be updated before running) but I have raised this request with the team that owns automations.
Having said that, more support for file support for connectors (as inputs and as outputs, pull and push) is activly in engineering discovery - we plan on picking up implementation of more support for files following that investigation.
Thanks for the feedback!
Pete
Thank you @Pete_Hartnett I actually had been asking about a feature to run an automation only when a specific field is updated a while ago but completely missed it being released - that’s great! I setup the automation just as you suggested having it trigger only when the last field in the table is update by the app, and it works like a charm for this and some other use cases.
Using the connector would still make app building easier since you can choose the single connector function, and it lists all the input that are required versus having to (in my case) choose 8 actions. That said, I suppose the new “Functions” feature could also help streamlining this.
I had another use case that I ended up putting on hold due to the limitation of PDFs in connectors. I wanted to use a connector to transfer PDFs from a Tulip table to an external service such as Dropbox.com or Box.net. Those services have APIs but I’m unsure if this would work even when Tulip comes out with the feature. My idea was to transfer final certs into a shared folder that our customers can access…sort of a poor man’s customer/supplier portal where they can retrieve their cert packages whenever they want.
