Our form is not sending submissions to DropBox

Again - your system is not sending the PDF or Dropboxing the files.

I've tried integrating DropBox with one of my forms and sent a test submission which worked fine at my end.

Could you try removing the DropBox integration and re-integrate it to see if that works? Please get back to us if the issue still persists. We will be happy to assist you further. 

That resolved it, but this seems to be the solution a lot lately... Any thing on my end to do that will not cause this issue so much?

For Dropbox integrations, there is a one exceptional scenario, if you want to know. After creating your integration and getting the first submission, if you change the related file's location on your Dropbox account, the integration won't create another file on the same address. So, the integration is not going to work anymore. If this is something you did, it is the possible reason for this issue.

However, if you are pointing somewhere else, please do let us know.

Regards.

Nope the same folder and dropbox location.

If that so, we need to wait and see. Please, track the activity you do after this fix. With that way, if it happens again, you can give us a more details about the issue. In addition, this issue could be related with the expiration of Dropbox API key, I found a explanation about when it is happening on Dropdown.

Please, see it from the below:

App access tokens effectively don't expire, but users can manually revoke tokens by going into My apps. In the case of apps with app folder access, if the user deletes the app folder, your app's access token will no longer be valid.

You should only process the authorization once, and save the access token for all future calls for that user. If an existing access token is invalid, (in which cases calls will return 401), you should prompt the user to re-authorize your app.

Please, do let us know, if there is an update from your side.

Thanks.

Maybe not related but I found that having a full stop at the end of my automated submission name made it not come through to my dropbox folder, (but be saved in my JotForm account).

i.e. if someone enters their name as "Steve." and your form is set to save the submission in Dropbox, with the "{Date prefix} and {name}", it won't come through to dropbox! I've got around this by telling people not to add any full stops at the end..

Thank you for more details about a possible bug, clontarffoundation. I have checked this on my own forms, but I could not replicate any issues with submissions being named with a full stop / period.

I've made multiple submissions with using the period at the end of the name fields, but I could not replicate mentioned issue:

All submissions were correctly being forwarded to my Dropbox folder, even if containing a period at the end:

Thank you for your report, but as of now, I can't seem to replicate such an issue with periods at the end of the file name / submission name preventing the integration from working correctly.

It may be a combination of periods along with some other change or setting that are causing it. If it is consistently failing on your end when you have a period at the end, clontarffoundation, please open a new support thread and we will be happy to examine your specific forms in more detail about whether the combination of periods at the end and some specific way how the form is set up are causing the issue on your end.

Thank you.

Thanks for the reply. Yes I just tried it myself and you're right - folders ending in a period are uploaded to my dropbox folder.... Online, that is.

My local Dropbox folder I have installed on my C Drive does not upload the folder however. This may be a dropbox thing, maybe it can;t create a folder ending in a full stop?... I've tried it with other characters such as "!" and ")", which upload to my online Dropbox folder and local Dropbox folder; it's just the ones with a period "." that don't upload to my local dropbox folder..

I've make a work-around for this by making a hidden textbox, which uses a concatenate type of formatting, to add a valid character after my input result. i.e. "Steve." + ")" = "Steve.)", which uploads fine.

Based on what you have mentioned it is very likely that you are using Microsoft Windows.

For example, I could name a file :c⁄⁄ within my Linux and open it with file reader without any issues, but if I transfer it to a drive that can be accessed by Windows, it will not know what to do with the same since it will see it as a drive attachment.

Since Dropbox does not care if the file is saved with dot at the end, or some other strange character, they will accept everything, while once they try to transfer it over to your Windows, windows might cause issues as it expects extension afterwards - so it might not see it as a folder.

Hope this helps, but this would be best to check in with DropBox support since they might have a way around the same.

Again, thank you for your posts, they will probably help others as well checking their local drive instead of online DropBox account.

My issues it works, then just stops... most of the time redoing the connection fixes it... So it seems to be something between Jotform and Dropbox API...  Just my take...

Could you check if the files uploaded to your JotForm are appearing normally in DropBox browser session? As we test it at our end, we're not able to replicate the issue and seems to be working fine. 

I've tried submitting your form with an attachment. Could you check if the submission has been received along with the file uploaded to DropBox?

It is working fine now... but it will stop and stop cold... I use the flag in Jotform to make sure I'm not missing forms... As a work around...

Great! It is good to know that it is working now and glad you came up with a workaround.

By the way, if you are checking the files into your Dropbox desktop app, I suggest to check them in the web version too. There may be syncing issues with the desktop app when a folder contains special characters as mentioned above.

Thank you!