Gravity Forms Dropbox - WordPress Plugin

Guide to Setting Up and Using Gravity Forms Dropbox

Gravity Forms Dropbox is not just a way to add another upload field to a form. The real value of the plugin is that it connects your WordPress form to cloud storage, so files submitted through the form land in a clear Dropbox folder, stay tied to the corresponding Gravity Forms entry, and do not turn into a chaotic pile of attachments on your site server.

This guide walks through practical setup decisions: how to prepare the form, connect Dropbox, create a feed, choose the upload field, configure the destination folder, use conditional logic, verify the result, and figure out why a file did not make it to the cloud. It also covers Dropbox Upload Field separately, which is the scenario where a visitor selects a file from their own Dropbox instead of uploading it from a device.

This material is written for a site owner, webmaster, or developer who already works with Gravity Forms and wants to set up file storage safely. It does not cover purchasing or activating a license. The focus here is on features, settings, testing, and troubleshooting for a product you already have access to.

What Problem the Form and Dropbox Connection Solves

A standard form with an upload field stores the file inside WordPress. That is fine for a small contact site, but real-world projects run into limits quickly: files take up hosting space, managers have a hard time finding attachments in the admin panel, and access to submissions has to be granted to people who do not need access to all of WordPress.

Gravity Forms Dropbox moves an important part of that process into the cloud. After a form is submitted successfully, the plugin can send uploaded files to a selected Dropbox folder. The Gravity Forms entry still keeps the information needed to understand what the user submitted and where to find the final file. This is especially useful when the site collects documents, portfolios, media assets, pricing materials, applications, coursework, or support attachments.

It is important to understand that the plugin does not replace the form itself. It works on top of Gravity Forms: the form collects the data, the File Upload or Dropbox Upload field handles the file, and the feed setting determines what happens to that file after submission. That means the quality of the result depends not only on Dropbox, but also on how the form is built, what restrictions are set on the field, and how notifications, page caching, and WordPress background tasks are configured.

Where the Integration Delivers the Most Value

The plugin is especially useful for sites where files need to reach the team quickly, but WordPress admin access should stay limited. Common scenarios include:

• Client requests with documents, scans, drawings, or photos.
• Resume, portfolio, creative work, or coursework submissions.
• Support forms where the user attaches a screenshot or an error file.
• Collecting materials for print, design, project estimation, or proposal preparation.
• Internal employee forms where files should go directly into a department folder.

In those cases, Dropbox is not just an archive for the sake of having one. It becomes part of the actual workflow. The team gets files in a familiar structure, while the site remains the intake point for data.

When the Plugin May Be Unnecessary

If the form only collects text submissions or occasional small attachments, the integration may add more configuration than value. It also will not solve problems caused by poor hosting, file size limits, incorrect MIME types, or broken JavaScript on the page. If the user cannot select a file in the form, you should first check the upload field itself, the form page, and WordPress rules before looking for an error in Dropbox.

Quick pre-launch check: if managers need the file outside WordPress, a cloud folder structure is required, and every submission must pass attachments along automatically, the integration makes sense. If the file is only needed by the site administrator once a month, standard storage in Gravity Forms entries is enough.

Two File Paths: Uploading from the Site and Selecting from Dropbox

Gravity Forms Dropbox supports two different workflows, and they are often confused. The first is sending files uploaded through the standard File Upload field to Dropbox after the form is submitted. The second is the Dropbox Upload field, where the user chooses a file from their own Dropbox through Dropbox Chooser, and the plugin then processes the selected links and, if a feed is configured, copies the files into the folder specified for the form.

From the site administrator's perspective, these scenarios only look similar on the surface: both involve a file and Dropbox. In practice, they require different solutions. The standard upload field is better when the user simply attaches a file from their device. Dropbox Upload Field is useful when your audience often stores documents in Dropbox and does not want to download them locally before submitting the form.

The Standard File Upload Path

In this setup, the user selects a file on their device. WordPress accepts the upload, Gravity Forms stores the value in the entry, and the Dropbox Add-On uses the configured feed to send the file to the right Dropbox folder. This path is easier to implement because it does not require the visitor to have a Dropbox account and relies on standard Gravity Forms behavior.

The most important thing in this scenario is to define clear field restrictions up front. In the upload field settings, check allowed extensions, file size, required status, label, and helper text. If the form accepts PDFs and images, do not leave the field open to every file type. Restrictions are not only about security, but also about team usability: the Dropbox folder should receive the materials you expect, not random archives and unsupported formats.

The Dropbox Upload Field Path

Dropbox Upload Field uses the Dropbox JavaScript Chooser API. The user selects a file from their own Dropbox, and the field value stores links to the selected files. Gravity Forms documentation specifically notes that this field is available when you configure a custom Dropbox app. That is why it should only be enabled when the workflow genuinely requires it.

This mode works well for audiences that already live in Dropbox: agencies, instructors, designers, photographers, HR teams, and support teams. But it comes with more conditions: you need to configure the custom Dropbox app correctly, set the domain for Chooser, define the right app permissions, and complete the connection in the Gravity Forms admin area. If you only need a regular upload from a computer, it is easier to start with the standard File Upload.

How to Choose the Right Mode

It is better to choose the mode before you build the form. If you create the form first and then try to swap a standard field for Dropbox Upload Field, you may accidentally change the notification logic, whether the field is required, and the expectations of managers who already work with the entries.

What to Check Before Installing on a Live Site

The Dropbox integration depends on several external conditions. If you skip the prep work, the error shows up later: the field looks fine to the user, the form submits, the entry appears, but the file never reaches Dropbox or the process stalls on a background request. Preparation takes less time than diagnosing those symptoms after launch.

Basic WordPress and Gravity Forms Requirements

First, confirm that the site meets the requirements for Gravity Forms and the official add-ons. For file integrations, what matters is not just the WordPress and PHP version, but also PHP extensions such as curl and openssl, because the plugin talks to an external API. If the site runs on an outdated environment or the host blocks outbound requests, the Dropbox feed may fail even if the form itself is configured correctly.

In the admin panel, open Forms > System Status and review the environment section. In practice, the most important items are the ones related to background tasks, loopback requests, SSL, and PHP extensions. If you already see warnings there, it is better to resolve them before enabling the Dropbox integration.

SSL and Internal Request Availability

For the Dropbox settings page, the documentation explicitly calls out the SSL requirement. If the site is available over an insecure protocol or the certificate is misconfigured, you can run into errors on Forms > Settings > Dropbox. This is not just a cosmetic issue: the Dropbox API expects a secure authorization flow, and both the browser and the server must trust the site address.

The second requirement is that the site must be able to perform internal HTTP requests. Gravity Forms uses background tasks for some operations, and the Dropbox feed depends on whether the site can send a request to its own internal service URL. If loopback requests are blocked by Basic Authentication, a firewall, Cloudflare rules, or server policy, the file may never be sent.

File Restrictions and MIME Types

Even if Dropbox is ready to accept the file, WordPress has to allow the upload first. The File Upload field follows WordPress rules for file types and MIME validation. So an odd upload error with DOCX, SVG, AI, or another format is not always related to Dropbox. Start by checking whether the format is allowed in WordPress and whether you restricted the extensions in the field settings.

A safe approach is to allow only the file types your process truly needs instead of opening the field to everything. If a department only needs PDFs and images, state that directly in the field, in the form description, and in the internal submission process. That lowers the risk of accidental attachments and makes the Dropbox folder more predictable.

Cache, Script Optimization, and Forms

A page with a form should not be served like a static article. Caching, JavaScript bundling, delayed script loading, and aggressive optimization can break dynamic forms, especially when AJAX, conditional fields, or external widgets are involved. Gravity Forms documentation recommends excluding form pages from cache and disabling problematic optimizations while troubleshooting.

Practical rule: before launching a form that handles files, create a test page, exclude it from cache, submit several entries with different file types, and only then move the form to the public page.

Installation and the First Dropbox Connection

The add-on is installed using the standard Gravity Forms workflow. The easiest option is usually the add-ons browser in the admin panel: go to Forms > Add-Ons, find the required add-on, install it, and activate it. If you are uploading a ZIP through WordPress, the path is Plugins > Add New > Upload Plugin. After activation, do not publish the form immediately. Open the integration settings and complete the Dropbox connection first.

The main screen is located at Forms > Settings > Dropbox. Here, the administrator connects a Dropbox account through OAuth. After clicking the connect button, the site redirects to Dropbox, where access must be approved for the selected account, and then returns to WordPress. If the user has both a personal and a work Dropbox profile, this is where choosing the correct one matters, because it determines which environment future files will be sent into.

What to Check After Connecting

Do not stop at the success message after authorization. Create or open a test form with a File Upload field, then configure a feed for it. Connecting the account only means the site can talk to Dropbox. It does not yet mean that a specific form knows which files to send or where to place them.

At this stage, it is useful to create a separate test folder in Dropbox, for example for an intake form. If the documentation or interface suggests that a new folder should be created in Dropbox ahead of time, do that before selecting the folder in the feed. This prevents the situation where an administrator tries to find a folder in the list before it even exists.

What Not to Do During Initial Setup

• Do not connect a staff member's personal Dropbox account if the files are supposed to belong to the company.
• Do not enable multiple feeds on one form without a clear reason, or it becomes harder to diagnose which feed processed the file.
• Do not change cache rules, notification formats, and Dropbox logic all at once. Test one change at a time.
• Do not publish the form until you have submitted a test file and checked the Gravity Forms entry.

The Feed as the Delivery Rule: The Core Gravity Forms Dropbox Setting

In Gravity Forms, many integrations work through feeds. For Dropbox, the feed answers the practical questions: which form sends files, which field is involved, which Dropbox folder receives the result, and under what conditions that should happen. So the feed is not a secondary tab. It is the center of the entire setup.

Open the form you need, go to Settings > Dropbox, and create a new feed with Add New. The documentation lists several core fields: feed name, upload field selection, destination folder, conditional logic, and saving the settings. The feed name is only visible in the admin area, but it helps support a lot: instead of something like Feed 1, use a clear name such as Brief files to Client Projects.

Selecting the Upload Field

The File Upload Field setting determines which files should be sent to Dropbox. If the form has only one upload field, the choice is obvious. If there are several, do not use the all upload fields option unless you truly need it. Different fields often mean different things: a contract, a photo, a project brief, or a supporting document. It is easier for the team when each field goes to the correct folder or at least does not get mixed with other file types.

For complex forms, you can create multiple feeds, each tied to its own field and folder. But that approach requires discipline: feed names must be clear, conditional logic must not conflict, and test submissions must cover every scenario.

Destination Folder

Destination Folder determines where files will land in Dropbox. The folder should reflect the way the team actually works. A bad structure looks like this: all files from all forms dumped into one shared folder. A good structure separates at least the site, the form, and the type of submission. For example, an agency might logically split materials into design requests, contract documents, and support files.

If you need a new folder, create it in Dropbox and then return to the feed settings. That is simpler and more reliable than assuming the structure will appear on its own. If folders are built dynamically from form data, only use verified values: submission number, entry ID, project name, or the selected service type. Do not build a path from a free-text field without sanitizing the value.

Feed Conditional Logic

Conditional logic lets you send files to Dropbox only when a condition is met instead of every time. For example, a form may accept several request types, but only those where the user selected Attach project files should be sent to Dropbox. In another case, the file can stay in the Gravity Forms entry or be handled by a separate process.

The strength of conditional logic is control. The weakness is the risk of a silent failure. If the condition is set up incorrectly, the form still submits, the user sees the confirmation, but the feed never runs. That is why, after configuring the condition, you should always create two test submissions: one where the condition is true and one where it is false. In the first case, the file should appear in Dropbox. In the second, it should not.

Folders, Naming, and Dynamic File Organization

The most common mistake with file-based forms is focusing only on the moment of submission. A few weeks later, what matters more is not whether the file reached Dropbox, but how quickly someone can find it. That is why the folder structure should be designed in advance. Gravity Forms Dropbox supports folder selection in the feed and can be extended through documented filters if the standard setup is not enough.

A Simple Structure for Most Sites

For most sites, three levels are enough: project or site, form, and submission type. For example, the folder may reflect a contact form, a job application form, or a document intake form. If submission volume is high, add another level by month, entry ID, or service type. But do not make the structure too deep: managers should not have to click through five subfolders to reach every file.

A good compromise is a form folder with subfolders inside it for each submission type. If the form collects documents for different departments, it is better to split by department. If there is only one department but many projects, it is more useful to split by project. The meaning of the structure should match the way people actually look for files later.

A Dynamic Path Through a Documented Filter

Gravity Forms documentation includes the gform_dropbox_folder_path filter, which lets you change the destination folder while the file is being processed. This is already a developer or advanced administrator task, because you need to understand where snippets should live and how to roll the change back. The example below appends the value of field ID 5 to the feed folder for form ID 10. Replace the form and field IDs with your own before using it.

add_filter( 'gform_dropbox_folder_path_10', 'site_dropbox_folder_by_project', 10, 6 );

function site_dropbox_folder_by_project( $folder_path, $form, $field_id, $entry, $feed, $file_url ) {
	$project_name = rgar( $entry, '5' );

	if ( empty( $project_name ) ) {
		return $folder_path;
	}

	$project_slug = sanitize_title( $project_name );

	return trailingslashit( $folder_path ) . $project_slug;
}

Add this kind of code through a child theme, a custom mini-plugin, or a trusted snippets plugin. Do not place it in WordPress core, Gravity Forms files, or Dropbox Add-On files. After saving it, submit a test entry with a clear field value and check whether the subfolder appears in the expected location.

How to Roll Back the Change

If files start going to the wrong place, disable the snippet, restore the standard folder in the feed, and run the test again. Any files already uploaded to Dropbox will need to be moved manually according to your internal process, because changing the code does not automatically rebuild the existing structure.

When You Do Not Need a Dynamic Path

If there are only a few folders, it is better to keep the setup in the interface. Code makes sense when the structure depends on entry data: project number, selected branch, document type, or submission ID. If the task can be solved with two feeds and conditional logic, start with the interface, because it is easier to maintain without a developer.

Custom Dropbox App and Dropbox Upload Field

You do not need a custom Dropbox app in every case. Official Gravity Forms documentation recommends the standard OAuth button connection for typical workflows. A custom app is needed when you want access to folders outside the default application folder or when you want to use Dropbox Upload Field, where the visitor picks a file from their own Dropbox.

This section matters because many administrators enable a custom app too early. The result is more settings, more permissions, and more points of failure, even though a standard File Upload already solved the problem. The right question is not how to enable a custom app, but why your specific form needs one.

What Changes with a Custom App

The administrator creates an application in the Dropbox App Console, chooses the access type, gets the App key and App secret, adds the OAuth Redirect URI from the add-on settings, and, if Dropbox Chooser is needed, specifies the site domain. To make the features work, the app needs Dropbox permissions related to reading, writing, sharing, and file requests. These steps should be handled by someone who understands which Dropbox account will own the application.

Do not keep the app keys in notes accessible to the whole team. Do not send them into support chat unless absolutely necessary. If a team member leaves the project or the application was created in the wrong account, review ownership and permissions. The person using the form only needs to know that the custom app is enabled. The technical keys should remain with the administrator.

How Dropbox Upload Field Works

The Dropbox Upload field uses Dropbox Chooser. The user clicks the button, selects a file from their Dropbox, and the field value contains preview links. If the form has a Dropbox feed configured, the processor copies the selected files into the folder defined in the settings, updates the Gravity Forms entry with new links, and only then sends notifications.

The field includes a Link Type setting: a preview link opens a view page, while direct download starts a download when the link is opened. The better choice depends on how the team works with files. For reviewing and viewing documents, preview is usually more convenient. For automatically passing the file into an external process, direct download can be more appropriate, but that scenario should be tested separately.

Team-Level Access Limitation

The custom app documentation notes that, due to Dropbox API changes, the add-on in its currently documented state does not support team-level access. So do not design the workflow as if the plugin will automatically gain access to the entire Dropbox Business team structure. If you need team folders, test that on a sample form and confirm the behavior in the official documentation or with Gravity Forms support.

Practical Example: A Client Project Files Form

Consider a scenario that comes up often for agencies and service companies. A client fills out a project brief form, selects a project type, attaches materials, and submits the request. The team should receive the text data inside the Gravity Forms entry, while the files should go into a Dropbox folder split by project type. This example does not require a custom app, because the user uploads the file from a device.

Goal

Build a form where files from the Project Files field are sent to Dropbox only for submissions where the user confirms they are attaching materials. After submission, the administrator should see the Gravity Forms entry, and the manager should see the file in the working Dropbox folder.

Preparation

• Gravity Forms and the Dropbox Add-On are installed and activated.
• Dropbox is connected on Forms > Settings > Dropbox.
• A Dropbox folder for project files has been created.
• The form page is excluded from aggressive caching and script optimization.
• The administrator has a test file of an allowed type and size.

Setup Steps

1. Create a new form or open an existing project brief form.
2. Add a File Upload field and label it clearly so users understand what materials to attach.
3. In the field settings, define the allowed extensions and file size limit if your process requires it.
4. Add a choice field, such as project type or a question about whether files are included.
5. Open Settings > Dropbox inside the form and click Add New.
6. Give the feed a clear name, choose the upload field, and select the Dropbox folder.
7. Enable conditional logic if the file should only be sent for a specific answer.
8. Save the settings and submit a test entry.

Expected Result

After the test form is submitted, a Gravity Forms entry appears in the admin panel, and the file shows up in the selected Dropbox folder. If you configured notifications, check whether the attachment or link behavior in the email changed. The Dropbox Add-On changelog includes fixes related to notification attachments, so if notifications behave strangely, make sure both Gravity Forms and the add-on are up to date.

A Detail That Often Causes Problems

If the file exists in the Gravity Forms entry but not in Dropbox, the problem is usually not the form field itself. Check the feed, conditional logic, destination folder, Dropbox connection, and background tasks. If the file never attached to the entry at all, start with the File Upload field, allowed file types, file size, and page cache.

How to Verify That the Setup Actually Works

Testing should simulate the real process. It is not enough to open the settings and see that an account is connected. You need to follow both the user path and the admin path: form submission, Gravity Forms entry creation, feed processing, file appearance in Dropbox, team notification, and a second submission with a different condition.

Minimum Test Set

• Submit a file of an allowed type and confirm that it appears in Dropbox.
• Submit the form without a file, if the field is optional, and make sure the feed does not create unnecessary errors.
• Test the condition where the feed should run.
• Test the condition where the feed should not run.
• Open the Gravity Forms entry and confirm that the links and field values look the way you expect.
• Check the notification email if the team receives a link or attachment by email.

If the form is public and important, add a test from a mobile device and from a regular user browser without WordPress login access. An administrator browser often hides caching, permission, and script optimization problems because the site may serve logged-in users differently.

Where to Look for Proof of Processing

For routine checks, the Gravity Forms entry and the Dropbox folder are usually enough. For troubleshooting, enable Gravity Forms logging: first the global switch on the settings page, then logging for Gravity Forms Core and the required add-ons. After submitting the form again, review the add-on log for entries such as feed check, API credential test, queue insertion, upload start, successful upload, or upload error.

There is no reason to keep logging enabled all the time. It is useful while diagnosing an issue, but once the problem is solved, it is better to turn it off and remove old log files, especially on a site that handles user data.

Security, Privacy, and Local File Storage

File-based forms always require care. Dropbox makes it easier for the team to access attachments, but it does not remove the need to think about personal data, retention periods, user permissions, and employee access. If the form accepts documents, resumes, medical records, financial materials, or any other sensitive data, folder setup is only part of the job.

Limit Access in Dropbox

Do not give the whole team access to the entire structure. Create separate folders for departments or processes and grant access only where needed. If files from the form must go into one shared folder, decide who is responsible for sorting them, deleting old materials, and moving them into the archive. Without that process, the cloud quickly turns into a second chaotic file server.

Check Local Copies and Notifications

Some setups may keep a local copy of the file in WordPress or use the file in notifications. Do not assume anything. Check how your actual form behaves. If privacy is critical, configure the process so unnecessary copies are not distributed by email, and limit access to Gravity Forms entries by role.

Also make sure your emails do not include files that should never be forwarded. For large or sensitive attachments, it is usually safer to notify the manager about a new submission and provide a link to the entry or the internal workflow than to attach the file directly to the email.

Do Not Expand Allowed File Types Without a Reason

If WordPress rejects a format you need, do not enable every extension at once. Check the MIME type, the business reason, and the risk. Gravity Forms documentation shows that you can use the WordPress upload_mimes filter to change allowed types, but those changes should be targeted. If the format is needed by only one department, it is better to limit it to that specific form and explain the allowed files in the field description.

Post-Launch Workflow: Who Reviews Files and What Counts as a Successful Submission

Technically, setting up Gravity Forms Dropbox is easier than fitting it into the team's daily workflow. Once the form goes live, it creates a new data path: part of the information stays in the Gravity Forms entry, part goes to Dropbox, part may end up in an email notification, and part may be used in a CRM or another process. If you do not agree in advance on where the source of truth lives, the team will start looking for the same file in three different places.

For file-based forms, it is worth defining a short operating procedure. It does not need to be a bureaucratic document. It is enough to describe who receives the notification, who checks the Dropbox folder, what counts as a successful submission, what to do with an incorrect file, when to move materials to the archive, and who is allowed to delete files. The more submissions flow through the form, the more important this layer becomes.

Source of Truth: Form Entry or Dropbox Folder

The Gravity Forms entry works well as a record: it shows the form fields, submission time, user email, technical notes, and processing history. Dropbox works well as working storage: that is where a manager opens, downloads, sorts, and forwards files. Do not try to replace one with the other. It is better to split responsibilities clearly: the form entry answers who submitted the request and with what data, while Dropbox answers where the actual file is stored.

If the team works only in Dropbox, still keep the link to the form entry in the workflow. It helps restore context: which service type the user selected, what comments they left, whether the send condition was met, and which email should be used for a reply. If the team works only in the WordPress admin area, Dropbox loses its value as shared storage. At that point, it is worth rethinking whether you need the add-on at all or whether standard attachments are enough.

File and Folder Names in Real Support Work

File names often come from users in unpredictable form: scan.pdf, final-final.jpg, document 1.docx. The Dropbox Add-On helps deliver the file, but it does not guarantee that the name will be useful to a human. That is why folder order should rely not only on the file name, but also on context: the form folder, a project subfolder, the entry ID, the submission type, or the processing date in your internal procedure.

If you need strict naming, evaluate whether the standard destination folder and conditional logic are already enough. For some teams, it is better to use the entry ID in the folder name or a subfolder than to try renaming every file. Renaming files through code is only reasonable if there is a documented filter and a clear test plan. If that requirement does not exist, do not overcomplicate the process too early.

How to Define a Successful Submission

A successful file submission should pass four checks:

• The entry is created in Gravity Forms and contains the expected fields.
• The file passes the form restrictions and is not rejected by WordPress.
• The Dropbox feed runs under the correct condition and sends the file to the right folder.
• The responsible team member receives a clear notification or sees the submission in their working queue.

If even one of those points fails, the submission should not be considered fully processed. For example, an entry without a file is not a Dropbox error if the user did not attach a document. A file in WordPress but not in Dropbox is a feed, background task, or API issue. A file in Dropbox without a manager notification is a communication problem, not a storage problem.

How to Update the Form Without Breaking the File Route

After launch, the form almost always changes: a field is added, an option label is renamed, the upload becomes required, or a notification is updated. Any of those changes can affect the Dropbox feed. If the conditional logic is tied to a specific field or answer choice, renaming or removing that field can stop file delivery.

Before changing a live form, create a copy of the form or test the changes on a staging page. After the edit, rerun tests across all important branches: with a file, without a file, with the condition met, with the condition not met, and with a large file that still falls within the allowed size. If a custom app is in use, also test the Dropbox Upload Field in a normal browser.

What to Include in a Short Team Guide

The team does not need internal documentation about hooks and OAuth. It needs instructions that help prevent missed submissions. Include:

• A link to the Dropbox folder or a description of the folder structure.
• A rule for matching a file to its Gravity Forms entry.
• Criteria for an incorrect file: wrong format, empty file, wrong project, or a missing required document.
• Who to notify if the file exists in the entry but not in Dropbox.
• When to delete, archive, or move files after processing.

That kind of procedure makes the integration useful not only to the administrator who configured it, but also to the people who work with submissions every day.

Why Files Do Not Reach Dropbox and How to Diagnose It

Troubleshooting should move from simple to complex. First, identify where the chain breaks: the user cannot choose a file, the file is not saved in the entry, the feed does not start, the Dropbox API returns an error, the destination folder is not created, or the background request never reaches WordPress. Each symptom points to a different set of causes.

The File Exists in the Entry but Not in Dropbox

Symptom: the user submits the form, the Gravity Forms entry is created, the upload field is filled, but the Dropbox folder is empty.

What to check: open the form settings at Settings > Dropbox, make sure the feed is active, the correct upload field is selected, and the conditional logic should run for this submission. Then enable logging and repeat the submission.

How to fix it: correct the field selection, destination folder, or condition. If the log shows that the feed is added to the queue but processing never finishes, move on to checking background tasks and outbound requests.

The Dropbox Settings Page Shows a 404 Error

Symptom: a 404 appears on Forms > Settings > Dropbox, or the settings page does not behave as expected.

Possible cause: Gravity Forms documentation connects these errors to Dropbox API requirements, SSL, and the need to update components. The site must work properly over a secure protocol.

How to fix it: check the SSL certificate, the site URL in WordPress, and whether Gravity Forms, the Dropbox Add-On, and WordPress are up to date. If the issue continues, prepare a short support report with the settings page URL, SSL status, component versions, and a screenshot of System Status.

The Log Stops After the Background Request Is Sent

Symptom: the log shows that the Dropbox processor sends a request to process the feed, but there is no successful file upload after that.

Possible cause: the internal request to the WordPress service URL is being blocked. This can happen because of Basic Authentication on a staging site, a firewall, security rules, Cloudflare, an incorrect site URL, or DNS issues.

How to fix it: check Tools > Site Health, Forms > System Status, and the Background tasks item. If the site is protected by Basic Authentication, do not paste passwords into random snippets. Point the developer to the official documentation on background tasks and decide whether service requests need to be temporarily allowed.

cURL error 28 or a Timeout

Symptom: the log reports a timeout while calling the internal service request or an external API.

What to check: site availability from the server, DNS, SSL, hosting limits, external security services, site load, and large file sizes. A timeout error does not prove that the Dropbox Add-On itself is broken.

How to fix it: repeat the test with a small file, disable cache and optimization on the test page, and review System Status. If the timeout repeats, contact your hosting provider with the log and the exact test time.

Dropbox Upload Field Does Not Appear or Does Not Work

Symptom: the field is unavailable, the Chooser does not open, or the user cannot select a file from Dropbox.

Possible cause: the custom app is not configured, the domain was not added to Chooser / Saver / Embedder domains, Dropbox app permissions are incomplete, or the form scripts are breaking because of cache and optimization.

How to fix it: check the custom app against the documentation, verify the site domain, OAuth Redirect URI, Dropbox permissions, and exclusion of the form page from script optimization. After each change, clear cache and test again in a normal browser.

Files Are Not Attached to Notifications

Symptom: the file appears in Dropbox, but the Gravity Forms notification does not behave as expected: the attachment is missing or the link is incorrect.

What to check: notification settings, field settings, and whether Gravity Forms and the Dropbox Add-On are current. The Dropbox Add-On changelog includes fixes related to notification attachments, so older installations may behave differently.

When to roll the setting back: if notifications become unreliable or emails begin including sensitive files, temporarily remove attachments from emails and leave the manager a link to the entry or an internal instruction for finding the file in Dropbox.

Compatibility with Themes, Cache, Notifications, and Payment Workflows

Gravity Forms Dropbox rarely runs in isolation. On a real site, it sits next to a theme, a page builder, a cache plugin, a security system, email notifications, and sometimes payment add-ons and CRM integrations. The more neighboring systems you have, the more important it becomes to understand where the Dropbox Add-On's responsibility ends.

Theme and Page Builder

If the form is embedded inside a hidden tab, popup, or builder block, make sure Gravity Forms scripts initialize correctly after the form becomes visible. With a normal File Upload, the issue may be less obvious. With Dropbox Upload Field and its external Chooser, the problem usually shows up faster: the button is there, but nothing happens or the file picker never opens.

The best test is to temporarily place the form on a plain page without a complex container. If everything works there, the problem is not Dropbox but the way the form is rendered or how the scripts are optimized. From there, you can dig into the builder settings, cache behavior, and JavaScript loading conditions.

Cache and Optimization

Forms that accept data and files do not pair well with aggressive caching. Exclude the form page from cache, disable repeated minification of Gravity Forms scripts, and check Cloudflare Rocket Loader or similar features if they are enabled. During testing, it is important to clear not only the server cache, but also the browser cache.

Payments and Delayed Processing

The Dropbox Add-On changelog mentions support for delayed uploads after successful payment. This is useful when a file should only be sent to Dropbox after payment is confirmed. But forms like that require extra-careful testing: run a successful test payment, a failed payment scenario, and a cancellation so you can see exactly when the Dropbox feed runs.

Do not test payments, Dropbox, notifications, and CRM logic all at once. First prove that the payment flow works, then that the Dropbox feed runs at the correct status, and then that notifications arrive with the expected content.

When Gravity Forms Dropbox Is the Right Choice

Gravity Forms Dropbox is worth using when your form collects files regularly, your team already works in Dropbox, and it is important to separate attachment storage from the standard WordPress admin area. The plugin is especially useful for submissions, documents, portfolios, support cases, and project materials where the file needs to reach a working folder quickly and remain linked to the form entry.

Before launch, verify three things: the form accepts the file correctly, the feed sends it to the right folder, and the site supports background requests and a secure Dropbox connection. If you need Dropbox Upload Field, separately evaluate whether a custom app is really necessary and what permissions it will require.

If the tested workflow matches the site's needs, you can download Gravity Forms Dropbox, deploy it on a test copy or staging page, and run a final scenario using real file types. That order is safer than enabling the integration immediately on a live form that is already receiving real submissions.