Skip to main content

Create a work area

Use this guide to add a work area for a slice of your organization's activity. You'll pick a template, set its coverage, grant access, and confirm the numbers look right.

  • Deployment: SaaS, On-premises
  • Role: Owner, Admin

The template you pick fixes the kind of coverage the work area accepts and cannot be changed later. Everything else stays editable.

Before you begin​

To create a work area, you need all of the following:

  • Owner or Admin on the organization: Creating and editing work areas requires one of these tenant roles. See Roles reference.
  • The reporting question this work area answers: A work area exists to scope a view. If an existing work area already answers the question, add people to it instead.
  • The repositories or committer emails it covers: Have these ready. See Work area templates reference for what each template accepts.

1. Pick a template​

Choose the template that matches the question you want answered:

QuestionTemplate
How is the whole organization doingCompany
What is happening in these repositoriesProject
What are these people working onTeam
What are these people doing in these repositoriesMixed
How do these existing work areas look togetherCombined

Your organization already has a company work area covering everything, provisioned when it was created. Create a second one only if you need a separate access list over the same coverage.

ScreenshotTemplate picker showing the five built-in templates: Company, Project, Team, Mixed, and Combined.

2. Set the coverage​

Fill in the coverage field the template requires:

  1. For a project work area, add repositories. Identify each by its stable id, or by a remote selector such as owner/repo. A selector keeps matching after a repository is re-cloned, so prefer it where you have the choice.
  2. For a team work area, add committer emails. Use the email that appears on the commits, which is not always the person's login address.
  3. For a mixed work area, add both. Coverage is the intersection, so only activity in those repositories by those people is reported.
  4. For a combined work area, add child work areas. Coverage is the union of the children, and the children stay live rather than being copied.

Each template caps how much coverage it accepts. See Work area templates reference for the limits.

3. Grant access​

Grant a work area role to each user or group that needs the work area. Coverage does not grant access, so this step is required even for the people the work area reports on.

  1. Add each principal, a user or a group, and set their work area role. See Roles reference for what each role can do.
  2. Optional: grant Self-only to people who should reach their own activity inside this work area without seeing aggregate dashboards.

Members of your organization who hold Global viewer, Admin, or Owner already read every work area and do not need a grant here.

ScreenshotWork area access panel showing users and groups with their assigned work area roles.

4. Confirm the work area reports what you expect​

  1. Open the work area and compare a recent period against a work area known to include the same activity. If the numbers are plausible, the coverage is right.
  2. If the work area is empty, confirm its coverage rather than its membership. An empty aggregate view almost always means the filter excludes the activity, not that access is missing.

Activity is processed asynchronously, typically catching up within about 15 minutes, longer after a bulk historical import. To check whether processing has caught up rather than guess, use the System Signals panel in developer traces, which reports pipeline lag directly.

Troubleshooting​

The work area is empty but the people are members​

Membership does not add activity. Confirm the repositories or committer emails in the coverage actually match the work the people are doing. See Work areas.

A developer's work is missing from a mixed work area​

Mixed coverage is an intersection. Activity is reported only when the repository and the committer are both covered, so a commit in a covered repository by an uncovered person is excluded by design.

Coverage cannot be saved because it exceeds a limit​

Each template caps repositories, developers, or child work areas. Reduce the coverage, or split the work area into several narrower ones and combine them.

The template is wrong​

A template cannot be changed after creation. Create a new work area with the correct template, move the grants across, then delete the original.

If this doesn't fix it​

Contact support with all of the following. Tickets missing these take longer to resolve:

  • The work area name, its template, and its complete coverage.
  • The period you expected activity in, and a work area where that activity does appear.
  • The grants on the work area, and the role of the person seeing the problem.
  • Your deployment kind and server version.