consolidating examples

Author: KathrynEE

docs/organizations/security/troubleshoot-permissions.md

@@ -294,7 +294,7 @@ You're likely signed into Azure DevOps with an incorrect identity. Complete the
 - [Deleted work items](../../boards/backlogs/remove-delete-work-items.md#delete-work-items)
 - [Azure Boards Team Administrator permissions and access](../../boards/get-started/permissions-access-boards.md)
 - [Custom rules](../settings/work/custom-rules.md#add-a-custom-rule)
-- [Custom fields](../settings/work/custom-rules.md#restrict-modification-of-select-fields-based-on-a-user-or-group)
+- [Custom fields](../settings/work/rule-samples.md#restrict-modifications-wits)
 - [Custom backlogs and boards](../settings/work/customize-process-backlogs-boards.md)
 - [Custom controls](../settings/work/custom-controls-process.md)
 

docs/organizations/settings/work/rule-samples.md

@@ -87,10 +87,10 @@ For the [On-premises XML process model](../../../reference/on-premises-xml-proce
 - Restrict who can create or modify a work item 
 - Restrict who can create specific work item types, such as Epics or Features 
 
-For example, you can restrict modification of work items by adding a rule to the work item type, usually within the **WORKFLOW** section. To learn more, see [Rules and rule evaluation, User or group membership rule restrictions](rule-reference.md#apply-ignore). 
+For example, you can restrict modification of work items by adding a rule to the work item type, usually within the **WORKFLOW** section. 
 
-You  restrict access to work tracking objects in one of two ways:
-- [Set a condition field rule](../settings/work/rule-reference.md), [a condition-based field rule](../../../reference/xml/assign-conditional-based-values-and-rules.md) or a combination of the two that applies to a group. You can restrict changes from being made to a field by specifying a qualifying rule and making it apply for a specific group. Conditional rules can include **CANNOTLOSEVALUE**, **EMPTY**, **FROZEN**, **NOTSAMEAS**, **READONLY**, and **REQUIRED** elements. 
+You restrict access to work tracking objects in one of two ways:
+- [Set a condition field rule](rule-reference.md), [a condition-based field rule](../../../reference/xml/assign-conditional-based-values-and-rules.md) or a combination of the two that applies to a group. You can restrict changes from being made to a field by specifying a qualifying rule and making it apply for a specific group. Conditional rules can include **CANNOTLOSEVALUE**, **EMPTY**, **FROZEN**, **NOTSAMEAS**, **READONLY**, and **REQUIRED** elements. 
 - By [adding WITs to the Hidden Categories group](../../../reference/xml/use-categories-to-group-work-item-types.md), you can prevent the majority of project contributors from creating them. You [can create a hyperlink to a template](../../../boards/backlogs/work-item-template.md) that opens the work item form and share that link with those team members who you do want to create them. 
 
 ---
@@ -167,6 +167,7 @@ TBD
 > </FIELD>  
 > ```  
 
+---
 
 <a name="fields"></a> 
 

docs/reference/xml/assign-conditional-based-values-and-rules.md

@@ -36,8 +36,10 @@ Field conditions are additional elements that you list inside a `FIELD` (Definit
 >  The value attribute is case-insensitive. Therefore, if the field reference name holds "YYY", matches include the values "yyy" and "YYY".  
 
 <a name="Syntax"></a>   
+
 ##  Syntax structure for conditional elements  
- The following table describes conditional rules that you can specify as child elements of the `FIELD` (Definition) element or `FIELD` (Workflow) element. These elements accept one or more of the following attributes:  
+
+The following table describes conditional rules that you can specify as child elements of the `FIELD` (Definition) element or `FIELD` (Workflow) element. These elements accept one or more of the following attributes:  
 
 -   `field`: A string that describes the field. Must contain 1 to 255 characters.   
 -   `value`: When the specified field has this value, the rules in the `WHEN` and `WHENNOT` elements are applied to the current field.    
@@ -151,8 +153,10 @@ Field conditions are additional elements that you list inside a `FIELD` (Definit
 
 
 <a name="DependentRequired"></a>   
+
 ##  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 a bug, a customer severity must be specified. If the bug was not reported by a customer, a customer severity is not required.  
+
+You can specify that a field is required only when another field contains a specific value. In the following example, when a customer reports a bug, a customer severity must be specified. If the bug was not reported by a customer, a customer severity is not required.  
 
 > [!div class="tabbedCodeSnippets"]
 > ```XML
@@ -173,7 +177,8 @@ Field conditions are additional elements that you list inside a `FIELD` (Definit
 <a name="DependentPickList"></a> 
 
 ##  Define a conditional pick list  
- The following example demonstrates a conditional pick list in which the allowed values for the Problem Type field are limited, based on whether the value of the ProblemCharacteristic field is set to Documentation.  
+
+The following example demonstrates a conditional pick list in which the allowed values for the Problem Type field are limited, based on whether the value of the ProblemCharacteristic field is set to Documentation.  
 
 > [!div class="tabbedCodeSnippets"]
 > ```XML
@@ -189,8 +194,10 @@ Field conditions are additional elements that you list inside a `FIELD` (Definit
 > ```  
 
 <a name="WhenChanged"></a>  
+
 ##  Define a field when the user changes another field (WHENCHANGED)  
- In the following example, when a user changes the value of the MyCorp.State field, the MyCorp.StateDate field is set to the current date and time, as the server clock shows.  
+
+In the following example, when a user changes the value of the MyCorp.State field, the MyCorp.StateDate field is set to the current date and time, as the server clock shows.  
 
 > [!div class="tabbedCodeSnippets"]
 > ```XML
@@ -213,9 +220,12 @@ Field conditions are additional elements that you list inside a `FIELD` (Definit
 > </FIELD>  
 > ```  
 >  <a name="WhenNotChanged"></a> 
-> ##   Define a field value based on a user not modifying a field (WHENNOTCHANGED)  
->  In the following example, when a user does not change the value of the MyCorp.State field, the MyCorp.StateDate field becomes read-only.  
-> 
+
+##   Define a field value based on a user not modifying a field (WHENNOTCHANGED)  
+
+In the following example, when a user does not change the value of the MyCorp.State field, the MyCorp.StateDate field becomes read-only.  
+
+
 > [!div class="tabbedCodeSnippets"]
 > ```XML
 > <FIELD refname="MyCorp.StateDate" name="Date Of Last State Change" type="DateTime">  

docs/reference/xml/change-workflow-wit.md

@@ -247,7 +247,9 @@ You can define rules that update fields whenever the following events occur:
   The following examples show some of the rules that are applied to system fields in the process template for MSF Agile Software Development.  
 
 <a name="DefineField"></a>  
+
 ###  Change the value of a field when the state changes  
+
  When the value of the **State** field for a work item is set to Active and the work item is saved, the values of the **Activated By** and **Assigned To** fields are automatically set to the name of the current user. That user must be a member of the Team Foundation Server Valid Users group. The value of the **Activated Date** field is also set automatically. The following example shows the elements that enforce this rule:  
 
 ```xml
@@ -269,8 +271,10 @@ You can define rules that update fields whenever the following events occur:
 ```  
 
 <a name="ClearField"></a>   
+
 ###  Clear the value of a field when the value of another field changes  
- When the value of the **State** field for a work item is set to Active and the work item is saved, the Closed Date and Closed By fields are automatically set to null and made read-only if you use the `EMPTY` element, as the following example shows.  
+
+When the value of the **State** field for a work item is set to Active and the work item is saved, the Closed Date and Closed By fields are automatically set to null and made read-only if you use the `EMPTY` element, as the following example shows.  
 
 ```xml
 <STATE value="Active">