--- title: Application Vulnerability Response remediation tasks and task rules overview description: Configure remediation tasks \(AVULs\) to help analysts and remediation specialists organize application vulnerable items \(AVI\) and analyze them in bulk. The criteria by which remediation tasks are formed is configured so that AVIs are automatically assigned into remediation tasks. Using remediation tasks, you can monitor progress and drive the remediation process more efficiently. locale: en-US canonical_url: https://www.servicenow.com/docs/r/australia/security-management/application-vulnerability-response/avm-rt-rt-rules-overview.html release: australia product: Application Vulnerability Response classification: application-vulnerability-response topic_type: concept last_updated: "2026-03-12" reading_time_minutes: 6 breadcrumb: [Configure Application Vulnerability Response, Configure, Application Vulnerability Response, Unified Security Exposure Management, Security Operations] --- # Application Vulnerability Response remediation tasks and task rules overview Configure remediation tasks \(AVULs\) to help analysts and remediation specialists organize application vulnerable items \(AVI\) and analyze them in bulk. The criteria by which remediation tasks are formed is configured so that AVIs are automatically assigned into remediation tasks. Using remediation tasks, you can monitor progress and drive the remediation process more efficiently. ## Tracking deferral counts for application vulnerable items and remediation tasks Track the number of times a vulnerable item, application vulnerable item, container vulnerable item, or remediation task is deferred. The **set deferral counts** scheduled job runs daily to post counts for the records that are deferred more than once in the Deferral count column. Records are displayed in the Multiple deferrals modules for VR, AVR, and CVR. ## Understanding remediation task rules Remediation task rules enable you to define how application vulnerable items are automatically grouped and assigned. A default rule **Vulnerability** is included in the base system that gathers AVIs based on their vulnerabilities. However, you can group by any other set of values in columns accessible from the AVI. These values could include configuration item \(CI\), vulnerability entry, and the like. There are task rules for Application Vulnerability Response that are included with the Vulnerability Response application that is available when you activate it. You can create multiple conditions with the condition builder. In the Group by section, after you set a field pair, another row appears. You can have up to six **Group by** selections. You can automate group assignment as well. See [Assign application vulnerable items in Application Vulnerability Response automatically](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/application-vulnerability-response/avm-assignment-rules.md) and [Filtering within Vulnerability Response](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/vulnerability-response/vr-filtering.md) for more information. For example, you can group your application vulnerable items by the configuration item, or by the product model. You can have one task rule for low severity vulnerabilities or low risk CIs. You can have another task rule for critical servers, and vulnerabilities that expose the company to more risk. See [Create, edit, and delete Application Vulnerability Response remediation task rules](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/application-vulnerability-response/avm-create-rt-rule.md) for more information about the options that you have available to you. A different set of rules can be used for application vulnerable items that expose the company to more risk. The remediation task name is appended to the remediation task rule **Group by** values to make the short description of the new record. When a new application vulnerable item is created, imported, or reopened after being closed, the rules are evaluated against it. An AVI is only evaluated once, automatically, unless it's reopened after being closed or the rules are reapplied manually. The following process is used for each new or reopened AVI: - For each remediation task rule, the AVI is compared to the remediation task rule filter. - For each rule where the remediation task rule condition matches, the rule pulls the data from the **Group by** selections on the AVI. It builds a group name and field. In this case, **High Risk: QID-32342:_Summary of QID-3242_** \(Name: vulnerability ID: vulnerability summary\). **Note:** The short description field is limited to 160 characters. Longer vulnerability summaries are truncated. The rule checks to see if there's a matching **Open** remediation task that is assigned to the same assignment group as the AVI. - If the task is found, the AVI is added to the existing task in the **Open** state. - If no task in the **Open** state is found, the rule creates a **High Risk: QID-32342** task, assigns it to the same assignment group as the AVI, and places the AVI in the remediation task. More than one remediation task rule can be defined to group different kinds of vulnerabilities. Since each vulnerability is compared with the remediation task rule conditions before putting it in a remediation task, too many rules might impact performance. Set up your task rules so the conditions help you avoid creating duplicate remediation tasks. By default, remediation task rules use the assignment group set by the **Assignment Rules** on the AVI when grouping the items and assigns the remediation task to match the AVIs. As part of the default task rule, the assignment of these remediation tasks is controlled by the rules in the **Assignment Rules** module. For more information on assignment rules, see . When a task rule is deleted from the form or list view, you have the option to delete all **Open** tasks created by that rule. Tasks not in the **Open** state are excluded. ## Reapplying remediation task rules When you want to change a remediation task rule, use the **Reapply** button on the remediation task rule page to rerun the changed rule on all active **Open** remediation tasks created by that rule. It deletes and recreates remediation tasks based on the changed rule automatically. **Reapply** only checks existing remediation tasks. After you select **Reapply**, the following message is displayed: `Reapplying this remediation task rule will delete and re-create the remediation tasks for this rule. Remediation tasks that are not in the Open state are not deleted`. ## Creating remediation tasks and adding AVIs manually You create an application remediation task \(AVUL\) from another application remediation task record and add application vulnerable items \(AVITs\) manually. See [Create an application remediation task manually in Application Vulnerability Response](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/application-vulnerability-response/avr-create-rt-manually.md) for more information. ## Remediation task rules and AVI creation and update If a CI or product model from a scan is associated with a known vulnerability, an AVI is created. After it's created, the AVI is evaluated against the conditions of remediation task rules for a match. If there is a match to an existing remediation task, the AVI is added. If a matching remediation task is not found, one is created for the AVI. If any property that is captured in the remediation task filtering conditions is updated or changed on an AVI, the updated AVI is also evaluated against the remediation task rules for a match. If there’s a match to an existing remediation task, the AVI is added. If a matching remediation task isn't found, one is created for the AVI. ## State rollup and rolldown If you update a remediation task to Open, or from Open to Under Investigation, the new state rolls down to all associated AVIs. State roll down occurs immediately after you change the state. State rollup from AVIs to the remediation task only occurs if all the AVIs on the task are in **Deferred** or **Closed- fixed** states. Rollup is done with the **Rollup application vulnerable item values to vulnerability and group** scheduled job, which runs every 15 minutes. The state is not rolled up until the job runs. For a state to roll up to occur from the AVIs to the remediation task, the all the AVIs must be in the same state. - **[Create, edit, and delete Application Vulnerability Response remediation task rules](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/application-vulnerability-response/avm-create-rt-rule.md)** You can create rules to automatically group application vulnerable items \(AVI\) into remediation tasks \(AVUL\) based on filter conditions. These rules automatically group AVIs as they're imported or manually created. - **[Create an application remediation task manually in Application Vulnerability Response](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/application-vulnerability-response/avr-create-rt-manually.md)** Create an application remediation task \(AVUL\) from another application remediation task record and add application vulnerable items \(AVITs\) manually. - **[Create auto-close rules](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/application-vulnerability-response/avr-create-auto-close-rules.md)** Use auto-close rules to close older AVITs automatically based on the filter conditions that you set. **Parent Topic:**[Configure Application Vulnerability Response](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/application-vulnerability-response/configure-avm.md)