Quick answer
Gravity Forms HubSpot Add-On 3.0.4 lets you disable its HubSpot tracking script when another integration already loads it. First identify the intended loader, then remove the redundant source. Browser tracking and CRM form delivery are different checks, so verify both after the change.
Inventory the places that can load HubSpot
Look in the theme or header-code manager, the HubSpot WordPress plugin if installed, your tag manager, and the Gravity Forms integration settings. Record which team owns each source. A script can be injected dynamically and therefore be absent from the initial page source.
In the browser Network panel, start a fresh page load with request recording enabled. Inspect the initiator of the relevant HubSpot request and the portal identifier. Do not count every HubSpot-related network request as another loader: one loader can fetch several resources and send several different event types.
Prove duplication before disabling anything
The strongest evidence is two independent installation sources attempting to load tracking for the same intended account. Two pageview records can also arise from navigation handling or custom event code, so removing a loader may not solve every duplicate-event report. Keep the observed symptom separate from your proposed cause.
If requests target different HubSpot accounts, stop and establish which account belongs to this site. Do not merge the problem into a generic deduplication task. A campaign landing page and the main site may have acquired different snippets over time, and each owner needs to understand the correction.
Choose the single owner that preserves consent
If the existing tag-manager or plugin implementation is already responsible for consent-aware loading, the new add-on setting can remove the redundant copy. Record the current configuration before saving it. Do not also disable the chosen primary source, or you will create a tracking gap.
Test the actual site policy in separate fresh sessions. Check the initial state, an accepted choice, a denied choice, and a changed choice where supported. Google Tag Assistant can help inspect Google consent events, but those events alone do not prove that an unrelated HubSpot integration obeys the same policy. Verify HubSpot's own observed behavior.
Use a small diagnostic worksheet
For each test session, record the page path, account identifier, loader initiator, consent choice, and requests observed after that choice. Use fictional form details and a unique test marker so the CRM record can be located without searching through real customer information.
Repeat the exercise on a normal content page and a page containing the form. If the form uses AJAX, submit once and watch whether a second initialization occurs after the confirmation. The initial page load can be clean while a dynamic component later reintroduces a loader.
Test marker: loader-review-001
Surface: public form page
Consent: record actual choice
Loader owner: record plugin or tag
Portal: record intended account
Entry ID: record after submission
CRM record: verify independently
Verify delivery without confusing it with tracking
Submit one sandbox or clearly identified test lead through the normal public form. Check the Gravity Forms entry, feed result, and corresponding contact or submission in the intended HubSpot account. Use timestamps and IDs to link the evidence.
If the entry exists but delivery fails, inspect feed configuration and its error. Re-enabling duplicate browser tracking is not a principled fix for a server-side feed failure. If delivery works but source attribution is missing, compare field mappings and the actual source values rather than assuming a pageview automatically populates every CRM property.
Check the deployment and keep a rollback note
After deployment, purge only the relevant page or asset caches needed for the changed loader configuration, then verify the public page again. An administrator's uncached view can differ from the visitor experience. Keep the original setting and the retained loader owner in the change record.
Monitor the next legitimate submissions through normal operations. Do not manufacture extra leads or conversion events to inflate a success count. The objective is a consistent tracking implementation with accurate account identity, appropriate consent behavior, and a form pipeline that still delivers the lead.
Illustrative diagnostic worksheet. Use your own test results.When to bring in help
For WordPress tracking support, bring the loader initiators, intended HubSpot account, consent state, and one redacted form-entry timeline. Avoid exporting the entire customer database just to diagnose a duplicate browser script.
Related troubleshooting
Check repeated scripts on AJAX forms.
Helpful references
Gravity Forms HubSpot 3.0.4 release notes. Google Tag Assistant consent debugging.