An empty assignee value needs a deliberate workflow outcome. Confirm the PHP fix and the business routing rule independently.
Quick answer
Gravity Flow 3.1.1 lists a PHP-error fix for conditional logic evaluating an empty Multi-User field. Update through the official channel after reproducing the case on staging. Then test the empty selection and the intended fallback branch. Removing the PHP error does not tell the workflow who should approve an entry when no user was selected. That outcome must match your saved rules.
Define what an empty selection means
A blank assignee can mean an optional reviewer was skipped, a required field was bypassed by conditional logic, an imported entry has incomplete data, or an old user reference no longer resolves. These cases may look similar in the editor but require different business handling. Ask the workflow owner to name the correct route for each before changing the form.
For an optional reviewer, proceeding to the next step may be correct. For an approval that requires separation of duties, a manual review queue may be appropriate. Do not convert every empty value to the administrator account as a quick workaround. That can silently change who receives sensitive submissions or who has authority to approve them.
Capture the failing entry without spreading its data
Record the form, step, field ID, plugin versions, current rule, and error timestamp. Use a synthetic staging entry with the same value shape instead of copying personal submission data into a public issue. Inspect whether the value is actually empty, a list containing an invalid identifier, or a different representation produced by an importer.
Export the form and relevant workflow configuration before editing. Preserve the conditional operator and any all-versus-any combination of rules. A change that fixes the empty case can accidentally change valid-user routing if the combined expression is rebuilt incorrectly. Keep a known valid entry as a control so you can compare both paths after the update.
Illustrative diagnostic worksheet. Values are examples, not measurements from a customer site.
Run the four fixtures that expose different failures
Submit one entry with no users, one with a single valid user, and one with multiple valid users. On staging, also test a reference to a user who no longer exists in that environment. Do not delete a real production account for this test. If the business allows inactive or role-restricted accounts, include that state and document what the interface permits.
For each entry, record the evaluated branch, assigned user or role, workflow status, notification recipient, and visible history. Check the actual notification log or test mailbox as well as the saved assignee. A workflow may show the correct next step while a separate notification rule chooses the wrong audience. Distinguish this from the separate empty-Role notification defect documented in the same release.
Apply the update and repair only the configuration that needs it
Install the supported Gravity Flow package on staging and repeat the exact fixture that failed. Check the PHP log for a new matching error. If the exception disappears but the fallback route is wrong, review the saved logic with the workflow owner. The code correction and the configuration correction should be recorded as separate changes.
Retest copied forms and imported workflows when their field identifiers differ. Confirm that any manual assignment is visible in history and that an entry cannot become permanently unassigned. For production, use a marked test entry with approved internal recipients and monitor the next real workflow cycle. Avoid bulk restarting stalled entries until their previous notifications and approvals have been reconciled.
How should stalled entries be recovered?
List the entries that stopped during the incident and inspect their current step and history. Some may already have advanced despite an error shown to the browser. Recover them using the supported workflow controls, one representative case first. Confirm the recipient and downstream action before processing the remainder. Keep an owner for unresolved entries so a successful new submission does not conceal work still waiting from the outage.
Working example
Use this as a read-only starting point or an evidence worksheet. Replace example identifiers with the approved staging fixture.
fixture: empty-assignee
form: staging-workflow
multi_user_value: []
expected_branch: manual-review
expected_recipient: configured-reviewer
observed_branch: record-after-test
Before closing the work
- Empty values do not cause a PHP error.
- The no-user branch has an owner.
- Valid selections retain expected routing.
- No unintended recipient receives a notice.
For help applying these checks to a live site, HandL WP WordPress support can review the affected configuration and verify the result. Continue with Gravity Flow display-only field routing when that adjacent issue matches your evidence.
Helpful references