Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Azure DevOps Server 2019
After you add or modify your workflow states for a work item type, define rules that apply based on the workflow state change. Adding rules to workflow states supports the following scenarios:
- Support an approval process
- Make a field required or read-only or another value based on State changes
- Automate closure of parent work items
Important
The Inheritance process model is available for projects configured to support it. If you’re using an older collection, check the process model compatibility. If your on-premises collection is configured to use the on-premises XML process model, you can only use that process model to customize the work tracking experience. For more information, see Choose the process model for your project collection.
Prerequisites
| Category | Requirements |
|---|---|
| Permissions | - To manage security groups and permissions at the project level, which includes setting rules for workflow states: Project Administrator. - To manage the work tracking area: Project Administrator or specifically assigned the Work Item Tracking permission. |
| Access levels | Basic access, which is typically sufficient for most users who need to manage work items and apply rules to workflow states. |
Understand workflow rules
Workflow conditions and actions you can set are illustrated in the following images. You can apply standard actions when a work item is created, in a selected state, or is moved from one state to another. These standard actions set the value of a field or make a field read-only or required. For this set of rules, you can specify one or two conditions and several actions.
Condition
Supported Actions
Set field value or make read-only/required based on State
Note
When you customize an inherited process, any projects using that process automatically reflect the customizations. To ensure a smooth transition, we recommend creating a test process and project, which allows you to test your customizations before you implement them organization-wide. For more information, see Create and manage inherited processes.
Understand workflow state and rule limits
Workflow rules get applied when you add or modify work items through any of the following interfaces:
- Web portal: Work item form, bulk updates, updates in query view
- Web portal: Board or Taskboard, move work item to column
- Visual Studio 2017 and earlier versions, work item form
- CSV file format: Bulk import or update
- Excel: Bulk import or update
- REST API: Add or modify work items
The following table summarizes the workflow state and rule limits for the Inheritance process.
| Object | Inheritance limit |
|---|---|
| Work item types defined for a process | 64 |
| Workflow states defined for a work item type | 32 |
| Rules defined for a work item type | 1024 |
When you define workflow states and rules, follow these guidelines to minimize performance issues:
- Limit the number of rules for a WIT: While you can create multiple rules for a work item type (WIT), more rules can negatively affect performance when users add or modify work items. The system validates all rules associated with the fields for the work item type when users save work items. In some cases, the rule validation expression might become too complex for SQL to evaluate.
- Limit the number of custom work item types: Reducing the number of custom work item types can help maintain optimal performance.
Define a rule
Before you define a rule based on workflow states, ensure the following elements are in place:
- Workflow states: Define the workflow states as described in Customize a workflow.
- Custom fields: If your rule requires a custom field, add it to the work item type as described in Add and manage fields.
- Security groups: If your rule requires a security group to grant or restrict changes that are based on user or group membership, define the security group as described in Add or remove users or groups, manage security groups.
For more information about defining rules, see Add a custom rule.
Set field value or make field read-only or required
With the first grouping of rules, you can specify one or two conditions and up to 10 actions per rule.
Example of ensuring team lead approval before active work
In this example, development teams want to ensure that no User Story gets worked on until approved by a team lead. The default workflow states are used, with the addition of a custom field, Approved By, and a security group, Team Leads Group.
Default workflow states
Rule requirements
To ensure approval before active work, define the following rules:
- Require the Approved By field to be filled in when the State moves from New to Active
- Restrict users who aren't in the Team Leads Group from filling in the Approved By field
- Clear the Approved By field when the State moves to New or Removed
Rule definitions
The rule requirements translate to the following four rule definitions.
Rule name
Condition
Actions
Approved By cleared when New
When A work item state changes to New
Then Clear the value of Approved By
Approved By cleared when Removed
When A work item state changes to Removed
Then Clear the value of Approved By
Approved By Read-only
When Current user is not member of group Team Leads Group
Then Make read-only Approved By
Approved By required
When A work item state changes from New to Active
Then Make required Approved By
Automate state transitions of parent work items
To automate State transitions for parent work items that are based on the State assignments of their child work items, see Automate work item state transitions.