Work areas
A work area is a saved, named scope over your organization's development activity. It answers one question: of everything the platform captured, which slice does this view report on. Every dashboard and report in the portal renders inside a work area.
- Deployment: SaaS, On-premises
A work area is not a team and it is not a project, even though two of the templates are named after those things. It is a filter with its own access list.
Coverage and membership are independent
Two settings sound alike and do different jobs:
- Coverage is whose activity the work area reports on. It is set by the work area's template and scope configuration.
- Membership is who can open the work area. It is set by granting work area roles to users and groups.
Changing one never changes the other. Adding someone as a member does not pull their commits into the numbers, and covering someone's commits does not let them open the view. This is the single most common source of confusion about work areas, and most reports of missing or unexpected data trace back to it.
A person can appear in a work area's coverage without being a member, and a person can be a member of a work area that reports on nobody but other people.
Templates decide what a work area can cover
Every work area is created from one of five built-in templates. The template is chosen at creation, fixes the kind of coverage the work area accepts, and cannot be changed afterward. The following table lists the templates:
| Template | Covers | You configure |
|---|---|---|
| Company | The whole organization | Nothing. Coverage is implicit |
| Project | Activity in a set of repositories | Repositories |
| Team | Activity by a set of people | Committer emails |
| Mixed | Activity in those repositories by those people | Both repositories and committer emails |
| Combined | The union of other work areas | Child work areas |
Mixed is an intersection and Combined is a union. A mixed work area reports only on activity that satisfies both conditions, so a commit made in a covered repository by someone outside the people list is excluded. A combined work area reports on everything any of its children report on.
Coverage limits
Each template carries its own caps, so a work area cannot grow past the size its shape is designed for. The following table lists the limits:
| Template | Maximum repositories | Maximum developers | Maximum child work areas |
|---|---|---|---|
| Company | Not applicable | Not applicable | Not applicable |
| Project | 50 | Not applicable | Not applicable |
| Team | Not applicable | 50 | Not applicable |
| Mixed | 50 | 100 | Not applicable |
| Combined | Not applicable | Not applicable | 20 |
Work areas migrated from an earlier version can exceed these caps. Those keep working, and can shrink, but an update must not grow a dimension that is already over its cap.
Every organization starts with a company work area
The platform provisions one default work area covering the whole company when the organization is created. It uses the Company template, it cannot be given explicit coverage, and it is the view that answers organization-wide questions.
Create further work areas when a group needs to look at a narrower slice, not because a team exists. A team with no separate reporting question does not need its own work area.
Combined work areas hold live references
A combined work area stores references to its children, not a copy of their coverage. When a child's repositories or people change, the combined work area reflects that on the next query without being edited. If two children overlap — the same repository or the same committer covered by more than one child — the overlapping activity is still counted once: coverage resolves as a single query across all children, not as each child's totals added together.
Children must be ordinary work areas in the same organization. A combined work area cannot contain another combined work area, and it cannot contain the default company work area.
Repositories can be named two ways
A project or mixed work area identifies repositories either by stable id or by a remote selector such as owner/repo. Selectors resolve to whatever repositories currently match at query time, so a repository that is re-cloned or re-registered stays covered without the work area being edited.
Related
- Create a work area — choosing a template and setting coverage.
- Work area templates reference — the exact coverage fields and caps per template.
- Roles reference — what each work area role can do.
- No activity appears for a developer — diagnosing coverage that excludes someone unexpectedly.