Quick answer
Gravity Forms HubSpot Add-On 3.0.4 includes a fix for a remote HubSpot form being saved when the local feed fails validation because a required setting is missing. Update and test the supported add-on build, then reconcile local and remote IDs. Do not delete every similarly named HubSpot form.
Preserve the failed-save evidence
Record the time of the attempted save, the local form ID, and the exact required-setting message. Check whether the feed already existed or was being created for the first time. A failed edit of an existing feed should not be treated as a completely new integration.
In HubSpot, note the identity and creation or modification time of the suspected remote form. Names alone are weak evidence because cloned forms and several websites can share similar names. Avoid renaming or deleting anything until you can show the relationship between the local feed and that particular remote object.
Confirm account and environment first
Make sure staging points to the intended test account or carefully isolated test destination. Production credentials copied into staging can make an innocent configuration test create a real CRM asset. Label your fixture clearly and contain any workflows or notifications that might react to it.
Record which website and integration own each remote form being examined. If another plugin also creates HubSpot forms, distinguish its activity from the Gravity Forms add-on. Two integrations using the same account do not necessarily share the same remote form or lifecycle rules.
Reproduce one invalid save on staging
Use a disposable local form and deliberately leave one required feed setting incomplete. Capture the validation response and inspect the remote account for a matching new or modified object. This is a controlled regression check, not permission to experiment against the live lead-capture form.
Run the test on the exact version intended for deployment. If the invalid save still changes a remote form, preserve the minimal fixture and raise it with the integration maintainer. Repeating the save many times makes cleanup harder and adds no useful evidence once the behavior is established.
Then prove the valid path still works
Complete the required settings and save the feed once. Record the resulting local-to-remote relationship, then submit a single fictional lead through the normal form path. Check the local entry, feed processing result, and remote submission. A saved feed is not proof that submissions are being delivered.
Verify the destination account, important property mappings, and any conditional feed rule. Use a unique test marker that contains no real customer data. If browser tracking is also configured, inspect it separately; a pageview or tracking request does not prove that the server-side feed delivered the entry.
- Keep local form ID and feed ID separate.
- Compare remote identity, not only its display name.
- Check both rejected and accepted save behavior.
- Confirm a test entry arrives exactly where intended.
Review suspected orphan forms carefully
A remote form may have existing submissions, automation dependencies, reporting usage, or embeds even if the local feed now points elsewhere. Ask the account owner to review those relationships before any cleanup. Export or preserve the necessary configuration evidence through approved processes.
Classify each object as active, duplicate but referenced, unreferenced test fixture, or unresolved. Only the last confirmed disposable group should be considered for removal, using the provider-supported process and appropriate authorization. Do not turn a troubleshooting article into a blanket deletion instruction.
Roll out with a clear owner
After the staging checks pass, deploy the supported add-on update and retest a normal live submission using the business-approved test procedure. Avoid creating multiple new remote forms as a monitoring technique. Watch ordinary incoming leads and integration errors for evidence of a regression.
Document which team maintains the feed and which team owns the HubSpot account. Include the approved remote ID in the handover. This prevents a later redesign from replacing the mapping merely because another form with a familiar name appears in a dropdown.
Keep the scope of the fix explicit
This release fix concerns validation and remote form saving. It does not guarantee that every historical duplicate is safe to remove, fix an expired connection, or decide contact ownership. Treat those as separate checks with their own evidence. A successful repair leaves a valid mapping and a verified submission trail, not simply a cleaner-looking list.
Illustrative diagnostic worksheet, not results from a customer site.When to bring in help
For Gravity Forms integration support, collect the local form and feed IDs, the remote HubSpot form ID, and redacted validation feedback. Do not share an entire CRM export. A small timestamped example is sufficient to investigate whether creation happened before validation or whether a different integration owns the remote form.
Related troubleshooting
Understand the separate HubSpot contact-owner setting change.
Helpful references
HubSpot 3.0.4 release notes.