Work area templates reference
Every work area is created from one of five built-in templates. The template fixes which coverage fields the work area accepts and the limits it enforces. Templates are supplied with the deployment and cannot be created or edited.
- Deployment: SaaS, On-premises
A template is chosen at creation and cannot be changed afterward.
Templates
The following table lists the built-in templates:
| Template | Key | Coverage type | Coverage field | Required |
|---|---|---|---|---|
| Company | company | whole_company | None | No |
| Project | project | repositories | repoStableIds or repoSelectors | Yes |
| Team | team | people | committerEmails | Yes |
| Mixed | mixed | repos_and_people | repoStableIds or repoSelectors, and committerEmails | Yes |
| Combined | combined | work_areas | childWorkAreaIds | Yes |
A company work area omits all explicit coverage. Every other template requires at least one entry in its coverage field.
Coverage limits
The following table lists the maximum coverage each template accepts:
| Template | Maximum repositories | Maximum developers | Maximum child work areas |
|---|---|---|---|
| Company | None | None | None |
| Project | 50 | None | None |
| Team | None | 50 | None |
| Mixed | 50 | 100 | None |
| Combined | None | None | 20 |
None means the template accepts no coverage of that kind, not that the limit is unbounded.
Work areas created by migration from an earlier version can exceed these limits. Those keep working and can be reduced, but an update must not increase a dimension that is already over its limit.
How coverage combines
The following table lists what each coverage type reports on:
| Coverage type | Reports on |
|---|---|
whole_company | All captured activity in the organization |
repositories | Activity in the listed repositories, by anyone |
people | Activity by the listed committers, in any repository |
repos_and_people | Activity in the listed repositories by the listed committers, the intersection of both |
work_areas | Everything the listed child work areas report on, the union of all of them |
Repository identification
Repository-scoped templates accept two forms, and a work area can hold both. The following table lists them:
| Form | Field | Resolution |
|---|---|---|
| Stable id | repoStableIds | Fixed. Matches one specific registered repository |
| Remote selector | repoSelectors | Resolved at query time from a normalized owner/repo or basename |
A remote selector keeps matching after a repository is re-cloned or re-registered, so it survives changes that would break a stable id.
Child work area rules
Combined templates reference other work areas rather than copying their coverage. The following rules apply:
- Children resolve at query time, so a change to a child is reflected without editing the parent.
- A child must belong to the same organization.
- A child must not itself be a combined work area.
- A child must not be the default company work area.
Dashboards and reports per template
The following table lists what each template renders:
| Template | Renders |
|---|---|
| Company | Activity dashboard, Tooling dashboard, AI adoption report |
| Project, Team, Mixed, Combined | Activity dashboard, Tooling dashboard |
The AI adoption report is available only on the company template, because it reports on organization-wide adoption rather than a scoped slice.
Related
- Work areas — what work areas are for and how coverage differs from membership.
- Create a work area — choosing a template and filling in coverage.
- Roles reference — the roles granted on a work area.