A group is a defined set of people who can act as assignees, reviewers or leads on a workflow stage.
Groups exist to solve a specific problem: most review gateways do not need a particular person, they need someone with the right authority. Legal needs to review it. A technical engineer needs to check it. A director needs to sign it off. Naming one individual makes the whole bid dependent on that individual being available.
How a group satisfies a gateway
When a stage is assigned to a group, everyone in that group is notified.
The stage's minimum approvals setting then determines how many of them need to act. If the gateway requires two approvals, the first two group members to review and approve satisfy it — the rest are not blocking anything.
So a stage requiring one approval from a five-person legal group clears as soon as any one of those five responds, rather than waiting on whoever happened to be named.
When to use a group
A stage needs a function rather than a person — legal, commercial, technical, finance.
Several people hold the same authority and any of them could approve.
The stage sits on a critical path, where one person's absence would stall the bid.
Approval is a senior sign-off, where the individual is likely to be travelling or in meetings.
Use a named individual instead where the review genuinely requires that person's specific knowledge — the author of a technical solution, or the account lead who knows the client's history.
Using groups with your workflow
When configuring a review or storyboard stage, set the default pool to a group rather than project team only. See Configuring Workflows.
The two choices behave differently in a way worth understanding:
Project team only | Draws from the team assigned to that project. Requires the project team to be configured properly at creation, and changes bid to bid. |
Group | Draws from a fixed set of people, independent of who is on the project team. Consistent across every bid that uses the workflow. |
Groups are usually the better choice for functional sign-offs, because the legal reviewer is rarely part of the project team but still has to approve.
Best practice
Build groups around functions and authority, not around individual bids.
Keep groups large enough that a single absence never blocks a gateway — three or more where possible.
Match the minimum approvals to the group's size and the risk involved. Requiring three approvals from a three-person group removes the whole benefit.
Review group membership when people change roles. A group containing someone who has left will still notify nobody useful.
Related articles
Configuring Workflows — the stages and gateways groups are applied to.
Roles and collaboration in the Answer Workspace — what assignees and reviewers can do.
Organisation & Team Seats — who exists in your workspace to be grouped.
Managing the question table — assigning individuals without a workflow.