Code reviewers are organized into review teams. Each team can set their own review conditions — for example, deciding to review PRs where certain files are modified, certain labels are applied, or a PR is being merged into a specific branch.
Use conditions to determine when the team will be assigned to a pull request. Like other expressions, these can leverage the vast majority of the GitHub API for the pull request.
You can put any number of users into a review team. Note that, currently, PullApprove teams have no connection to GitHub teams.
Each team can decide how many approvals are required, how many reviews are requested, and what happens if the author of a PR is also a reviewer.
Team pull requests
On the "reviewers" page for your organization, you'll be able to see a list of the teams and the pull requests that they are currently reviewing:
What about GitHub team review requests?
The PullApprove GitHub integration will only create review requests for individual users. It will never send a review request for an entire GitHub team.
While settings now exist to convert team requests into individual requests, we prefer to keep the GitHub integration simple and focused on individual users.
Workflow step condition or team condition?
Steps and teams can both have conditions, and they can be used for similar things. When used together (ex. your "In review" step), you might find yourself wondering where to put a condition.
Phase conditions should be used if the same rule applies to all teams, without exception. An example of this might be to only require review if the PR is being merged into the repo's default branch:
If the rule can't be applied to all teams, or if you want to apply different rules to different teams, then you should use a team condition instead.
The most common example of this is to assign a team to PRs based on the files that are modified:
In short, if a rule can obviously be applied to all pull requests for all teams, then use a phase condition. And if not, then use a team condition.