Quick answer
In a Gravity Flow User Input step, assigning a role is not equivalent to assigning every user who holds that role. Under the all-assignees policy, the documented requirement includes each named user, one user from each assigned role, and each assigned email field. If every named reviewer must act, represent that requirement explicitly and test it with separate identities.
Write the business requirement without plugin terms
Ask whether the process needs one representative from each team or a response from every named person. These are different workflows. A support team may need one available operator, while a committee may require several individual reviewers.
Write the expected outcome in plain language: for example, one finance representative and one legal representative must complete their fields. Or write that both Alice and Ben must submit. Use fictional users when documenting the example. Only then choose the assignment configuration that represents that requirement.
Separate notification audience from completion
A role notification can reach multiple people even when only one member needs to complete that role's assigned work. Receiving the email does not prove each recipient is independently required. This distinction can explain why a step advances while some recipients have not opened the message.
Do not solve that surprise by adding repeated notifications. More email will not change the assignee policy. Inspect the step's selected users, roles, email fields, and conditional routes. Also distinguish a User Input step from another step type whose settings may behave differently.
Watch for overlapping assignments
Gravity Flow documents that when a user and that user's role are both selected, the user's completion can satisfy both assignments. Do not treat that configuration as two independent approvals. If the business needs separation of duties, design and test that requirement explicitly.
Review multiple-role membership and role changes with the workflow owner. A person may represent more than one team in the account system. An apparently separate pair of role labels can still include the same human. The plugin configuration should not be used as evidence of independent review without checking those identities.
Build a small staging matrix
Create fictional accounts representing two members of the same role and a third person in another role. Use harmless entry values and prevent production emails or downstream actions during the test. Record the selected policy and expected result before each submission.
Test a step assigned to one shared role, a step assigned to two named users, and a step with an overlapping named user and role. Observe the completion timeline and the next-step transition after each controlled submission. Test an unassigned account as a negative control: it should not gain editing access just because it received a forwarded message.
Case | Assignment | Expected business question
A | one shared role | is one representative enough?
B | two named users | must both people complete?
C | user plus same role | can one action satisfy both?
D | unassigned account | is editing correctly denied?
Check incomplete work and the next step
Include a save-progress action where that feature is enabled. Saving an unfinished response should not be confused with completing the assigned task. Record which fields are editable and which required values still block completion. The policy test should examine behavior, not just inbox labels.
When the final required action is submitted, verify that the intended next step runs once. Check the notification recipient and any downstream integration with fictional records. An assignment change is not fully tested if the review looks correct but triggers an unwanted customer message or duplicates another operation.
Apply changes without rewriting history
Before modifying a live workflow, identify in-progress entries and agree how they should be handled. Do not restart all entries to force them into a new policy. Completed actions, emails, and external updates may already exist and must not be repeated blindly.
Keep a settings snapshot and the staging results. Document the intended treatment of existing entries separately from new submissions. After the approved change, observe a legitimate new entry through completion and confirm its outcome against the original business requirement. That is stronger evidence than assuming the phrase all assignees means every person on an email list.
Illustrative diagnostic example. Use your own redacted evidence.When to bring in help
Use Gravity Flow workflow configuration support when a review must meet a specific organizational requirement. Bring a fictional assignment matrix and expected outcomes, not confidential application content.
Related troubleshooting
For the adjacent diagnostic path, read Gravity Flow assignee identity and entry access. Keep its evidence separate from this test so a change in one component does not hide a failure in another.
Helpful references
Gravity Flow user-input settings.