I’m encountering some challenges with the DocsAutomator Action. It functions correctly when executed via the action builder or layout builder, but problems arise when I try to run it on my phone in the published environment.
The issue lies in the transfer of two specific fields from Glide to the PDF - these are lookup fields that extract data from an Airtable data source. Interestingly, other fields which utilize the same relation function properly. Is there a limit to the number of lookups that could be causing this?
Does anyone have any suggestions on how to troubleshoot this issue? Is this a known problem or has anyone else experienced similar hurdles? Any guidance or insights would be greatly appreciated. Thank you!
As an illustration, here’s a PDF example with the missing fields, generated when the action was run in the published environment. When the same action is executed via the builder, these two fields are populated correctly.
It may help to add a ‘wait for condition’ in your action sequence. The condition would be when lookup field 1 is not empty and lookup field 2 is not empty.
You’d have to play around with the wait time a bit but a second or two might work.
I tried implementing the ‘wait for condition’ in the action sequence as you advised, but unfortunately, it didn’t work.
It’s quite perplexing since it again operates as expected in the builder, but not in the published environment. I’m wondering if there could be an issue with accessing the relational data source in the published environment?
Hmmm indeed
I considered the possibility of a limit to how many lookups per relation can be transferred to DocsAutomator. Therefore, I attempted creating one relation per lookup, as well as running all lookups via a single relation. However, I still obtained the same result. Both methods worked in the builder but not in the published version.
Considering that I transfer a lot of columns to DocsAutomator, I thought I might have hit a limit to the number of columns allowed for transfer. As a result, I tried creating a separate document that only included the two problematic fields to test this theory. However, I still ended up with the same result.
I attempted to use PDFMonkey instead of DocsAutomator, but the outcome remained the same. The two fields are transferred in the builder but not in the published environment.
I attempted to reduce the number of columns used within the Glide data table, in case I was reaching some kind of limit. Unfortunately, this didn’t change anything - the result was the same.
Sometimes you have to, but as Eric mentioned it’s always safest to convert them to integers first. Either of the following two math formulas can be used, depending on the use case: