Glide not sending data to DocsAutomator

Hello. I have spoken to Rupert from DocsAutomator regarding my issue. He also had seen my Google Doc template and tried the production process inside the Glide app as a team.

On production, PDF generation works well, but clients are facing issues sometimes.

Attached is the screenshot. We can see that the PDF generation is completed. But from Glide the data was not sent to DocsAutomator.

This case happened several times. Maybe 3 or 4. The weird part, I never encounter this issue while in the production phase. It’s the first time happened on the user side.

So, it failed 2 times. First, on their side. Second, on my side when I tried to fix the issue. So, it was on the second attempt on my side it worked.

But remember, this case happened occasionally. Does the Glide team know how no data may be sent? Please need your help :pray: Thank you so much!

@david

Can you describe the process inside Glide for preparing the data that is sent to DocsAutomator?

Are there computed columns, User Specific columns, or Row Owners involved in the process anywhere?
The most likely explanation is there is a specific set of circumstances where the Data parameter is empty when the action is triggered.

Thank you for the reply.

Computed column: There are 2 computed columns. All of them the type is template columns.

User-specific column: There is no user-specific column. Only user profile data, which are their name and workplace. The trigger only shows if they have filled these 2 data on user profile data.

Row owners: I don’t understand what it means by row owners.

So, the data is being sent to DocsAutomator in total 23 data.

  • Filled by user column = 18
  • Computed columns = 2
  • User profile data = 2
  • Image = 1 (generated using Pexels or they just can paste the image link; this is a pre-requisite before triggering the action)

If the data parameter is empty when the action is triggered, I don’t know why after the second generation it worked. After the first action is triggered, there is no change. I just trigger the action again.

And also this case is happening sometimes. Maybe the frequency is 10%,

It could be that there is a delay involved in computing the data, which may explain why it works on the second attempt.

I have no idea what your action sequence looks like, but one thing you could try is adding a short wait condition just before triggering the DocsAutomator action. That might help.

Another thing you could do is set up a logging table, and add a row to that table containing the data payload every time the integration is triggered. This would help confirm if the action is being triggered with an empty payload, and may provide further clues.

What I would always do when using PDFMonkey, which might be related, is have an if-then-else column called “Validation” in my table.

Say “Variable A” is empty then null, “Variable B” is empty then null. Continues all the way to the last option, then true. It makes sure that all required variables are loaded.

1 Like

I’ve applied the condition. But it is still the same.

So, I’ve noticed this is the pattern:

  • One time failed user side
  • One time failed on my side
  • After that, it worked

So, this is not efficient. It supposed to generate 1 PDF, but at the end it needs 3 quota of DocsAutomator, and 15 quota edit from Glide (actually just needs 5) :disappointed_relieved:

Can you show us how you’re setting up the condition and the button to trigger it?

Generally, it must be a case of Glide not loading the required data before the action is executed, so no data is “seen” by Glide before loading it to a variable and sending to DocsAutomator.