ACTIONS: DocsAutomator problem


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.

Thank you for the suggestion, Eric.

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?

1 Like

Are you using any row owners?

No, I’ve also tried creating a new relation and lookup fields without success.

1 Like

Hmmm those would be my top suggestions. I’ll have a play around with it and see if I can come up with something.

Hmmm indeed :slight_smile:
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.

Ok so it’s definitely those 2 fields.

What can you tell us about those two fields specifically… what is the flow? How are they different from your other lookups that are working?

So it’s a Template > Relation > Lookup
The template is a text and date combined with ", "



Relation + the two problematic lookups

Lookup 1

Lookup 2

Source data for lookup 1:

Source data for lookup 2:

1 Like

Oooof that relation seems fragile but appears to be working. I haven’t used airtable before so that could be adding another layer to things.

I’d suggest converting that date in your relation to a number first. Generally speaking any relations with dates makes me nervous.

…but it also might be a bug.

Haha indeed. I might try to find a better key. I’ll let you now how it it goes.

1 Like


As Eric mentioned before, I’d change your date values to text/string and submit them to verify if DocsAutomator has any issue with your date format.


1 Like

In Sweden there is an expresion that translate to: “redo it, do it properly.”

I was able to pull the Airtable record ID in the form via a dropdown, hidden behind other values (displayed as)

New relation



It works! Definitely a “learn by your mistakes” scenario.

Thank you both for your help.

And to anyone stumbling upon this post, don’t use dates in relations :wink:


Glad you got it working! :mechanical_arm:

I also like how you removed the empty space in your template that forms the relation.

We can all sleep better now :wink:

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:

Year(Date) * 10000
+ Month(Date) * 100
+ Day(Date)

The above returns a numeric representation of the date in YYYYMMDD format.

Year(Date) * 100
+ Month(Date)

And the above returns a numeric representation of the year & month in YYYYMM format.


This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.