Work tracking, process, and project limits

  • Artikel

TFS 2017 | TFS 2015 | TFS 2013

This article defines operational and object limits placed on work tracking operations and work tracking customization. In addition to the specified hard limits on select objects, certain practical limits apply. When you customize work item types (WITs), consider the limits placed on objects.

Work items and queries

When defining work items or running queries, the following operational limits apply.

Object Limit
Long text field 1 M characters
Work item tags assigned to a work item 100
Work item links assigned to a work item 1,000
Attachments added to a work item 100
Attachment size 4 MB to 2 GB
Query execution time 6 minutes
Query results 20,000 items
Query length 32,000 characters
Shared queries under a folder 999 queries

The default maximum attachment size is 4 MB. You can change the maximum size up to 2 GB.

To improve query performance, see Guidance to create high-performing queries.

Backlogs, boards, and teams

When working with teams, work item tags, backlogs, and boards, the following operational limits apply. Default and maximum limits.

User interface Limit
Backlogs 999 work items
Boards 400 cards
Taskboard 800 work items
Teams 5,000 per project
Work item tags 150,000 tag definitions per project

Each backlog can display up to 999 work items. If your backlog exceeds this limit, then you may want to consider adding a team and moving some of the work items to the other team's backlog.

Additional notes:

For the On-premises XML process model, you can modify the backlog and taskboard limits by editing the ProcessConfiguration.xml file. For details, see Process configuration XML element reference.

Projects

Azure DevOps Services limits each organization to 300 projects per organization. Above 300 projects certain experiences, such as connecting to the organization from Visual Studio, start to degrade.

For on-premises Azure DevOps Server, there are no hard limits to the number of projects. However, you may find performance issues if the number of projects approaches 300. If you plan to migrate your on-premises collection to Azure DevOps Services, you'll need to observe the maximum limit of 300 projects. If your collection has more than 300 projects, you'll either need to split the collection or delete older projects.

For more information, see Migrate data from Azure DevOps Server to Azure DevOps Services.

Process customization

A number of limits are imposed on the number of objects that you can define for a process. To learn about process models, see Customize your work tracking experience.

The following table lists the maximum number of objects that you can define for the ON-premises XML process model. While these represent hard limits, practical limits may apply.

Object On-premises XML
Number of processes you can have in an organization 64
Work item types defined for a process 64
Fields defined for a collection 1024
Fields defined for a process 1024
Fields defined for a work item type 1024
Picklists defined for a collection N/A
Picklist items defined for a list 2048
Picklist item character length N/A
Workflow states defined for a work item type 16
Rules defined for a work item type 1024
Portfolio backlog levels defined for a process 5
Categories defined for a process 32
Global lists defined for a process 256
List items defined within a global list 1024
Size of imported process template 2 GB

Note

For the On-premises XML process model, you can define an approximate total of 10K items for all global lists specified across all WITs.

Practical limits

We recommend that you consider the following guidance in order to minimize performance issues.

  • Minimize the number of custom fields you define. All custom fields contribute to the total allowed for a process, collection, or organization. Note that you can specify different behavior for the same field in a different WIT. That is, you can specify different rules, picklists, and more.
  • Minimize the number of rules you define for a WIT. While you can create multiple rules for a WIT, addition rules can negatively impact performance when a user adds and modifies work items. When users save work items, the system validates all rules associated with the fields for its work item type. Under certain conditions, the rule validation expression is too complex for SQL to evaluate.
  • Minimize the number of custom WITs you define.
  • Minimize the number of reportable fields you define. Reportable fields impact performance of your data warehouse.

Note

Work Item Rules Validation Exceeds SQL Limits: A single SQL expression is defined per project to validate work items whenever they are created or updated. This expression grows with the number of rules you specify for all work item types defined for the project. Each behavioral qualifier specified for a field results in an increase in the number of sub-expressions. Nested rules, rules that apply only on a transition or conditioned on the value of some other field, cause more conditions to be added to an IF statement. Once the expression reaches a certain size or complexity, SQL can't evaluate it any more and generates an error. Removing some WITs or eliminating some rules, can resolve the error.

Migrate and import limits

When determining to migrate from on-premises to Azure DevOps Services, there are several size limits that you may encounter. These limits include:

  • Database size is above the recommended size
  • Largest table size is above the recommended size
  • The database metadata size is above the supported size

To learn more, see Migrate data from Azure DevOps Server to Azure DevOps Services and Troubleshoot import and migration errors.