Quick answer
Check whether the User Input step has an In Progress email enabled. A save can trigger a notification even though the step is not complete. Match messages to save events, reminders, and completion events before changing SMTP. Reduce unnecessary notifications through a reviewed configuration change, not by asking people to stop saving their work.
Define what counts as an unwanted message
Ask the recipient which message is noisy and what information they actually need. A reviewer may want a notice when work is assigned and another when it is ready for handoff, but no update for every partial edit. A collaborator may genuinely need in-progress updates. The right configuration follows that distinction.
Record the notification name, subject, recipient, entry ID, and send time for a few examples. Redact message bodies if they contain client data. Do not judge the problem only by an inbox count: several entries, multiple templates, and forwarded copies can make one event look much larger than it is.
Match saves to workflow and mail evidence
Use a staging entry with a long text field or another safe partial task. Save progress several times without completing the step. Record the timeline and capture outgoing messages. Then complete the step once and record the final notification separately. This gives you a controlled comparison rather than a guess based on production noise.
For a fictional configuration with four saves and three recipients per save, the expected total is twelve message copies before any completion notice. That arithmetic is an example, not a claim about your installation. Count the actual recipients and events because conditional routing can change who receives each update.
Inspect the notification families independently
Review the step's In Progress, Complete, and Assignee email settings, along with any reminder schedule. Also inspect initial form notifications and connected CRM automations. Two systems can send similar messages for different reasons, so disabling one Gravity Flow setting may not remove every duplicate-looking email.
Do not confuse a broad recipient selection with an overly frequent event. Sending to too many people and sending too often are separate problems. Record both the event rule and the recipient rule, then decide which needs a change. Keep access permissions and reviewer assignment separate from email preferences.
Keep the useful handoff signal
Write the proposed notification policy in plain language. For example: acknowledge assignment, retain permitted reminders while work is waiting, and tell the next team when the step is complete. If another team must review partial work, identify the particular event or deliberate handoff they need instead of broadcasting every save.
Test any recipient or event adjustment on staging. Avoid assuming that changing a notification automatically changes workflow state or assignment. Verify that the entry remains editable by the intended people and that saved partial values still appear when the reviewer returns.
Check long forms and multiple reviewers
A short test can miss the people most affected by noisy updates: reviewers filling long forms, editing over several sessions, or collaborating on one entry. Use fictional data to exercise those paths. Record whether a save from one person changes the content or recipient conditions used by the message.
Do not change required-field validation or default completion status as a shortcut to fewer emails. Those settings control whether work can be saved or completed and deserve their own acceptance tests. The notification fix should preserve the existing business rule about incomplete work.
Measure the result without suppressing legitimate mail
Compare event-to-message counts before and after the reviewed change using the same fixture. Confirm that the next owner still receives the intended completion notice and that scheduled reminders remain understandable. Keep a test for a failed or interrupted save so the team does not mistake missing work for a quieter inbox.
After deployment, ask the affected recipients to check a small sample over the normal work cycle. Record which messages remain expected. Avoid global mail suppression or server-level filtering that hides unrelated operational notices. Keep the old configuration and a concise rollback plan, remove temporary test entries, and close the task only when both saved work and useful handoff messages are verified.
Illustrative diagnostic example, not customer measurements.When to bring in help
Ask for Gravity Flow email diagnostics when notification volume affects several teams or other systems also send updates. Bring the notification names and redacted event counts. Keep saving behavior intact while the message design is reviewed.
Related troubleshooting
Verify Save Progress and completion behavior separately.
Helpful references
Gravity Flow User Input settings.