Skip to main content

Hello! :)

I’ve been working on this for the last 6 hours but I can’t for the life of me figure this one out..

What I am trying to achieve:
I am trying to create a process where Google Forms captures data, inputs said data (names, emails, etc.) to an agreement in Google Docs. After this I want said newly created doc with all the relevant info to be sent as an agreement via HelloSign.

 

Problem:

I have managed the first two steps, i.e. populating the doc based on the data from forms. Hooray! :-D

I am unable to get that doc over to HelloSign and then further. In “DropboxSign” I use “Send Signature Request from Template”, but the issue is that I am trying to get the template (the created doc) over to HelloSign but I can’t…. Isn’t there any upload function here? How do I get this to work?

Bonus:

I obviously do not want to send the same template every time, so I would need HelloSign to select the correct template based on the whole chain of events..

 

Thanks so much for having a look - I am at a total loss here :)


Br,

N

Hi ​@TimFinnegan 

You need to create the template in Dropbox Sign.

Help: https://faq.hellosign.com/hc/en-us/articles/211241477-How-to-create-a-template

 

 


Hi!

I have created a template there, but how do I populate the template with the correct data from the Google Form? 

Br,

Tim


@TimFinnegan 

If you configured the Dropbox Sign Template correctly in Dropbox Sign, then those fields should appear in the Dropbox Sign Zap step after you select the Dropbox Sign Template to use.

 

You can then map dynamic variables from previous Zap steps.
Help: https://zapier.com/help/create/basics/set-up-your-zap-action


Thanks so much for your time, but I still cannot figure it out. How do I get the previous values to the agreement in HelloSign? Should I add {{AdvertiserName}} that worked when I got the data from Google Forms to Google Docs? If I simply add the normal fields (textbox1, etc.) they will need to be filled each time and none of the data from the previous step is incorporated.

 

I would basically want to do the exact same thing I did in the first two steps - Get data from the previous zap into the agreement. Currently I cannot. I read through both articles. The first one simply tells me how to set up a template - I have done so, but it does not tell me how I get the data from a previous zap. The second article tells me how that should happen, and indeed it worked between Google Forms and Google Docs, but I am unable to get that data to the HelloSign document…?

What is the correct configuration in HelloSign that you talk of? :)


Hey again!

So I finally got this step - In the HelloSign template, the correct setup was to mark the dynamic fields (i.e. the ones I wanted to populate) as “Sender” and then use the merge fields. This allowed me to populate the merge fields with the data from the previous steps :)

 

Edit:
And now I all of a sudden get “bad_request”. I read through the articles, nothing. This sure isn’t made easy… I’ve spent over 8 hours on this project and am starting to lose hope. My first test worked, then it just decided to give “bad_request” even though the input is the same. Can someone please explain this to me like I am 5? I just do not understand how this can be so complex!

 

Edit2:

So I manually populated all the dynamic fields to make sure the issue was not with the form. Guess what? “bad_request” again… How can it be a “bad_request” when there is no request being made?

 

Edit3:

TIL that you cannot change the font or the size of the font. This will create a “bad_request” error. LoL. My field testing of this can almost work as a manual for the newbies :D

To be continued.. (hopefully not)

 


Me again ​@Troy Tessalone :)


Now I get a “bad_request” error, again. The AI tells me: 

The error "bad_request" often occurs when required data is missing or incorrectly formatted. In your case, the placeholders like {{275234897__0b0a2545}} indicate that data is expected from a previous step. If these placeholders appear in the "Step argument values," it means the data wasn't passed correctly. Ensure that the previous step is providing the necessary data for fields like "subject," "signers," and "custom_fields." Additionally, check if any custom fields exceed character limits, as this can also cause a "bad request" error.

 

  1. I have no such placeholder in the dropbox template, see screenshot below:

     

  1. The formatting is the exact same as it was yesterday. The only “new thing” is that I activated API via Dropbox. 

 

Any clue why it stopped working and any clue what the placeholder that Zapier mentions is? I cannot find it anywhere and all the steps that are mandatory are populated correctly...

 


..oh and here’s a screenshot which indicates that all the fields are correctly populated:

 

 


Investigating further, to my utmost astonishment, I found that using the older form still works. 
I cross checked both forms and they are (obviously) the same questions but with different answers. I even checked the “data in” section in testing, and everything except the answers were identical. 

This means that some input is “wrong” according to Zapier/Dropbox but I have no clue what and why (also, if I don’t know this the whole form becomes unusable since people will fill it with real life data...!?).

 

This is tragically comical at this stage. Is there anyone out there who has experience of trying to make this incredibly simple Zap work?


@TimFinnegan 

To hire help, there is a directory of Certified Zapier Experts: https://zapier.com/experts


Hi Troy,

 

That’s a bit disappointing to be honest. I feel that this is a very basic process I am trying out and there is no guidance and no help.

 

Imagine you go to a car shop, test drive a car, comment that you don’t understand how the brakes work, and the sales rep tells you that you can “hire a certified expert”….

 

If setting up the most basic function on Zapier is this hard and if help is this hard to come by, I think I’ll just move on to some other solution :)

Thanks for trying I guess


@TimFinnegan 

Similarly, drivers take their cars to mechanics to fix issues, because the issue is outside of the driver’s knowledge/skill/comfort level or is a better use to trade money for time.

 

Possible root issues (and could be a combo of issues):

  • Might be how the GForm is configured
  • Might be how the Dropbox Sign template is configured
  • Might be how the Zap steps are configured
  • Might be related to the data you are testing with

 

Questions such as:

  • Have you tried turning the Zap ON and testing live?
    • Have you check your Zap Runs history details to see the DATA IN/OUT for each step to help you trace the data flow and troubleshoot?

 

Notes:

  • Most Zap app configurations are unique per the user requirements.
  • In your case, the GForm form and esign template are custom factors.
  • Depending on the apps involved in the Zap steps each of those apps have different requirements and settings.
  • Some issues can be harder to troubleshoot only thru screenshots.
  • Sometimes it takes process of elimination to isolate the issue to fix. (e.g. field by field)

 


Hi,

 

Thanks for a good reply! :)


As I said in my earlier post, the data IN is exactly the same, and hence I am at a total loss.. Identical GForm input, identical process, data from the form is the only thing that differs, and the car breaks down..

I have not tried it live, since I want it to work first (the whole idea of testing?). 

 

My main point here is that the setup is incredibly simple, yet even for this incredibly simple task, the solutions seem hard (if found at all!). 

 

Regarding the car analogy:
I am now testing the car, and it seems it is indeed a space ship where even the most fundamental things are too complex. My reasoning then is to simply go to a car shop that has a simpler car on sale (make.com) or to a place that will teach me the most basic thing (how to start the engine). ;)


@TimFinnegan 

Automation is all about the details, where a single extra invisible space can be the root cause of an issue.

 

Often troubleshooting automation comes down to SHOWING more than TELLING. (could be phrased incorrectly and/or could be interpreted incorrectly)

The few screenshots provided thus far are not enough info for us to have full context.

Generally, these screenshots are recommended to be provided to help with troubleshooting:

  • how your Zap steps are outlined and configured in EDIT mode
  • for live Zap Runs, show the DATA IN/OUT for each step
  • any encountered errors in Zap steps while testing or in a live Zap Run
  • in the apps being used, how the fields are configured that may be related to the issue

 

I have not tried it live, since I want it to work first (the whole idea of testing?). 

  • Testing live is still testing, and will be reality.
  • Results during testing can be different from the results when testing live.
  • You should always test live before truly going live with the automation.

 


Reply