If Gravity Forms sends some submissions to the wrong team or sends nothing for one dropdown choice, inspect notification routing against the saved entry values. A renamed choice or an uncovered branch can break recipient selection even when the mail provider works normally.
Separate whether to send from where to send
Notification conditional logic decides whether a notification should run. Routing supplies its recipient. They are different decisions, and a routing configuration does not automatically provide a safe fallback for every input.
The official routing guide explains that changed choices require reviewing the saved routing rules. Begin with the correct form ID and notification, not another form with a similar title.
Compare a failing entry with the rule
Use one controlled test entry and record the exact saved value of the routing field. Then open the form's notification settings and inspect Send To > Configure Routing. Check the field, comparison and destination for each branch.
If the field's choices were edited, reselect the current intended choice in the affected rule and save. A label that looks similar to the previous label is not sufficient evidence that the stored configuration matches.
| Test choice |
Intended recipient |
What to prove |
| Sales |
Controlled sales test inbox |
One intended notification |
| Support |
Controlled support test inbox |
No accidental sales copy |
| Other |
Approved general inbox or explicit no-send policy |
No blank unresolved destination |
| Empty optional choice |
Defined policy |
Behavior is deliberate, not accidental |
Saved value: Matches the intended rule. All branches: Recipient policy defined. New test entry: Intended inbox receives once. Sensitive branch: No unintended copies sent. Explanatory checklist, not a customer test result.
Build complete and non-overlapping coverage
Write down every permitted choice, including an empty value if the field allows it. Match each to an approved recipient policy. If more than one rule matches, inspect the actual resolved recipients rather than assuming the interface uses the first match only.
Use notification conditional logic when the requirement is to suppress a notification. Do not rely on a blank recipient as a substitute for a clear no-send rule.
Keep sensitive messages restricted to the intended team. Adding a catch-all mailbox can expose submissions that a specialized branch was meant to protect. Confirm fallback ownership before enabling it.
Test new submissions, not only resends
Create synthetic entries for each branch using mailboxes you control. Record the entry ID, notification name, resolved recipient and observed delivery. A manual resend can differ from the original event path, so finish with a new normal submission.
If the destination resolves correctly but the message is rejected or quarantined, continue with the notification delivery diagnosis. Changing routing cannot repair a provider authentication failure.
Do not resend a batch of customer entries to test a new rule. Notifications may contain private fields and can trigger downstream automation. Keep temporary logging brief and redact recipient details from shared evidence.
For help, send the routing-field structure and a synthetic failing example to HandL WP. The finished configuration should cover every allowed choice and preserve each team's intended access, not merely produce one successful email.
References reviewed October 5, 2026. Examples are explanatory, not customer test results.