Quick answer
When Gravity Flow skips an intake review after a new service is added, compare the submitted field value with the step's conditional assignment rules. A visible service label is not enough. Confirm that at least one intended reviewer matches the stored value, then test an explicit fallback on staging.
Capture the skipped step before changing it
Open one affected entry and record its form ID, workflow step, selected service, and timeline. Keep this evidence with the installed plugin versions. If the entry never reached the review step, the problem may be an earlier condition or branch. If it reached the step but had no assignees, focus on assignment.
The User Input documentation warns that unmatched conditional routing can leave a step without assignees and allow it to be skipped. The troubleshooting guide also describes automatic approval when an Approval step has no assignees. Treat a missing reviewer as an operational risk, not merely a missing email.
Compare labels, values, and old entries
A field might display "Website maintenance" while storing "maintenance". Write down both. Check whether the rule compares the value that the entry actually contains, whether the field was replaced, and whether the rule still points to the correct field ID. Renaming a label does not prove that every integration now sends a new value.
Use three records: a service that worked before the edit, the newly introduced service, and an unexpected or blank value. Keep the records fictional. For older entries already in progress, inspect their stored values separately. They may reflect the old form definition even though a new visitor sees the updated menu.
Verify that the reviewer still exists
Check the assigned user or role in the destination environment. A workflow copied from staging can reference an account that does not exist in production. A role can exist but contain nobody suitable for the task. A mailbox address can also differ from the WordPress account the reviewer uses.
Use the least access needed for this business process. Do not make every reviewer an administrator to solve assignment. Ask whether the reviewer can see the entry, edit only the intended fields, and complete the step. A successful assignment with excessive access is still a failed rollout.
Design the fallback deliberately
Document what should happen when a service does not match. One useful policy is to send the inquiry to a designated triage reviewer who can classify it. Another is to reject invalid input at the form boundary. The business owner should choose the outcome; a developer should not silently assign every unknown service to the first team.
Gravity Flow documents a step-assignees filter for custom fallback behavior. If code is required, scope it to the specific form and step, review the resulting permissions, and test it against the installed version. Avoid a global fallback that changes unrelated workflows. A monitored exception queue is more informative than pretending every inquiry matched normally.
Run a small acceptance test
Create a staging copy with outbound email and CRM writes contained. Submit the three service cases and complete each as the intended reviewer, not as a privileged administrator. Record the route, actual assignee, visible fields, and next step. A test should fail clearly when the assignment differs from the written policy.
- The original service still goes to its established reviewer.
- The new service reaches the newly configured reviewer exactly once.
- The unmatched case reaches the explicit fallback or is rejected as intended.
- A reviewer from another service cannot inspect the entry without authorization.
Release without replaying every inquiry
After approval, apply the smallest configuration change and watch the next real inquiries. Review already-skipped entries individually with the business owner. Restarting them all may resend acknowledgements or CRM actions, so identify side effects before any replay. Keep the old configuration and the test record with the change note.
If assignment is now correct but the reviewer receives no email, investigate notification delivery as a separate issue. The entry timeline and inbox can establish whether the workflow is waiting for a person even when an email provider delayed the message. Do not undo a correct routing fix simply because email needs its own repair.
Illustrative diagnostic example, not customer measurements.When to bring in help
Bring the form ID, step ID, three redacted entry timelines, and a list of intended reviewers to HandL WP workflow troubleshooting. Ask for a narrow routing correction with access checks, rather than permission changes across the site.
Related troubleshooting
Separate editable fields from routing inputs.
Helpful references
User Input step settings. Troubleshooting workflow issues. Client intake workflow example.