Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
This article provides examples of custom rule definitions. Define all custom rules for a work item type. The article provides examples for both the Inherited and On-premises XML process models.
Before you add custom rules, see Rules and rule evaluation and Add a rule to a work item type (Inheritance process).
Define a dependent required field
You can specify that a field is required only when another field contains a specific value. In the following example, when a customer reports an issue, set the custom Customer Reported field to True, and the Severity field becomes required. If the issue isn't reported by a customer, a value for the Severity field isn't required.
Clear the value of a dependent field
The following example shows how to define a custom rule to clear the value for Story Points when you change the Start Date.
Set a dependent field value
The following examples show how to map the values of the Size field depending on the value selected for the custom Tee-Shirt Size field.
The Tee-Shirt Size pick list consists of four values: Small, Medium, Large, and X-Large. Four custom rules assign the Size field when you change the Tee-Shirt Size field to a specific value. To simplify usage, the default value of the Tee-Shirt Size is Small.
Edit field dialog for Tee-Shirt Size field
Custom rule
Four custom rules
Require a field value upon state changes
The following example shows how you can require specification of the Remaining Work field when the task workflow State changes to Active.
Clear the value of a field when the State is Closed
To automate clearing the Remaining Work field when closing a task, define a custom rule as indicated.
Restrict creation of work items by a group
A custom rule that restricts the transition to the Proposed state category of a work item type effectively disallows creation of work items of that type. By applying the rule to a specific group, you disallow that group from creating work items of that type.
The following custom rule restricts a project team from creating work items as the Proposed state category maps to the New workflow state.
Restrict modification of work items by a group
For an Inheritance process, prevent users from modifying a work item by setting the deny permission for a group on an Area Path. For an On-premises XML process, place restrictions on each workflow state for a group that prevents them from saving the work item in any state.
You can't define a custom rule that restricts modification of work items of a specific type. You can only specify restriction by state. If the user doesn't change the state, they can modify other fields, unless all fields are read-only for the group.
To restrict a group of users from modifying select work items of any type, assign those work items to an Area Path. Define a security group, and then set restrictions for editing work items for that Area Path for that group as shown in the following image. For more information, see Set permissions and access for work tracking, Create child nodes and modify work items under an area path.
Restrict state transitions
For inherited processes, any-to-any state transitions are automatically defined. This workflow definition allows users to advance the workflow state from new to completed, but also to move backwards in case that action is needed. When defining custom rules to restrict a transition, keep in mind that if a user makes a mistake in updating the workflow, they might not be able to correct it. For example, they could update the status by moving a work item card to a later stage on the board, but not move it back.
Tip
Consider restricting a state transition for some but not all users. That way, if a user makes a mistake, they can ask another team member to reset the State value to bypass the restriction.
Before defining state transition rules, review Rules and rule evaluation, Auto-generated rules and How workflow states and state categories are used in Backlogs and Boards.
Restrict modification of closed work items
Depending on your business processes, you might want to prevent users from continuing to modify or update work items that are closed or completed. You can add rules to work item types to prevent users from re-opening closed work items.
For the inherited process, you can add a rule that restricts state transitions. For example, the following rule restricts transitioning from closed to the other two states, New and Active.
Note
The A work item state moved from ... condition is available for Azure DevOps Server 2020 and later versions.
Note
Depending on the rule action you specify, either the Save button on the work item form is disabled, or an error message displays when a restricted user attempts to modify the work item.
Hide or restrict modification of a field based on a user or group
When you select the Current user is a member of group... or Current user is not a member of group... condition, you can hide a field, make a field read-only, or make a field required.
For example, the following condition hides the Justification field for members who don't belong to the Fabrikam Fiber\Voice group.
Note
Work items are subject to rules applied to them. Conditional rules based on user or group membership are cached for your web browser. If you find yourself restricted to update a work item, you may have encountered one of these rules. If you believe you've encountered an issue that doesn't apply to you, see Work item form IndexDB caching issues.
Restrict modification of select fields based on a user or group
You can customize work item types to restrict who can modify a specific field for a work item type.
You can use one of the following two conditions to make select fields required for a user of a security group or for users who aren't members of a security group.
current user is a member of a group...current user is not a member of a group...
Tip
To avoid rule evaluation problems, specify Azure DevOps security groups instead of Microsoft Entra ID or Active Directory security groups. For more information, see Default rules and the rule engine.
For example, you can make the Title or the State fields Read-only for select users or groups.
For example, the Priority field, for the User Story work item type, becomes read-only for members of the Fabrikam Fiber\Voice group. When a user in this group opens a User Story, they can't change the value in the Priority field.
