Quick answer
Find the notification that sent the welcome message and inspect its event plus conditional logic. Tie acceptance wording to the actual acceptance decision at the intended workflow step. A form submission, a generic approval-or-rejection event, or workflow completion alone is not proof that a client was accepted.
Identify the message, not just its subject
Record the affected entry ID, recipient, message timestamp, notification name, and workflow timeline. Two notifications can share a similar subject. A CRM can also send a separate welcome email after receiving the lead, so first establish whether WordPress produced the message in question.
Use a test inbox to reproduce the behavior with a fictional inquiry. Keep a neutral acknowledgement separate from the acceptance message. "We received your inquiry" and "Your project is accepted" describe different business states. Correct delivery of the wrong statement is not an email transport problem.
Inspect how the notification is triggered
Gravity Flow can invoke standard Gravity Forms notifications from a workflow step or define a notification within that step. It also offers event-based notifications. Inventory all three paths for the relevant message, because editing one copy may leave another active.
The official notification guide says the approved-or-rejected event applies across steps and statuses unless constrained. It also notes that workflow completion can occur regardless of final status. Scope the decision condition to the intended step and outcome. Do not rely on the word "complete" to mean that somebody approved the client.
Map the intended sequence
Write down the minimum state sequence: inquiry received, review pending, accepted or declined, owner assigned, and next action communicated. Decide whether welcome should follow acceptance immediately or wait until an owner confirms responsibility. Both policies can be reasonable, but the template and workflow must agree.
Place the message in the approved branch or use carefully reviewed step-and-status conditions appropriate to the installed version. When modifying a live workflow, record references from other steps before changing order or deactivating anything. The repair should not make already-pending entries bypass review.
Run the negative cases first
Submit one inquiry and leave it pending. The receipt may send, but the welcome must not. Reject a second inquiry and verify the decline path. Accept a third and confirm the expected welcome recipient and content. These cases establish whether the message is genuinely tied to acceptance rather than merely to activity.
Add a later update or later approval step to the accepted test case when the workflow includes one. Check that it does not send another welcome. Also test any expiration behavior that can produce an approved status automatically. The business owner must know whether that automatic path is allowed to communicate acceptance.
- Pending inquiry: acknowledgement only, no acceptance wording.
- Declined inquiry: deliberate decline response, no welcome.
- Accepted inquiry: correct welcome at the intended step.
- Later workflow activity: no unintended repeat welcome.
Separate duplicates from premature sends
A duplicate send after acceptance and a premature send before acceptance need different evidence. For duplicates, compare notification IDs or names, step visits, event triggers, and any external CRM automation. For premature sends, compare the message time with the decision time.
Do not suppress the symptom by disabling all form notifications. That can remove the only acknowledgement a prospect receives and hide genuine reviewer alerts. Change the specific trigger or condition, keep necessary operational messages, and test both the customer and internal recipient paths.
Review customer impact before replaying
If real prospects received acceptance wording too soon, give the business owner a list of affected entry IDs and the messages involved. They should decide whether clarification is needed. Do not automatically send a correction campaign or restart every entry while the scope is still uncertain.
After the technical fix, retain the before-and-after settings and the four-case test record. Monitor the next accepted and declined inquiries, including any downstream CRM email. A passing result means the message, recipient, timing, and actual business state all agree, not simply that a notification appears in a sent log.
Illustrative diagnostic example, not customer measurements.When to bring in help
Ask HandL WP to trace the notification event when messages misrepresent acceptance or repeat across steps. Bring the notification name, event, condition, entry ID, and redacted delivery timestamp rather than changing SMTP providers first.
Related troubleshooting
Audit workflow recipients before changing email delivery.
Helpful references
Notification step and event behavior. Client intake workflow example.