# Strategies
Strategies are a critical step in designing your system that defines *What*, *When*, and *How* to implement your patching.
## Create a Strategy in v10.0+
In OneSite Patch, creating new patching strategies is comprised of four simple steps:
1. **Overview** - Enter a **Name**, **Description**, and **Enable** the Strategy.
2. **What to Patch** - Include all the Products you'd like to patch and filter patches as necessary.
3. **When to Patch** - Set a schedule for when you'd like your Strategy to run.
4. **How to Patch** - Set up how you'd like to patch to specific Business Units and add Transitions that let you control the behavior of how the strategy is executed and how patches are deployed.
Below is an example that incorporates several features of the new Strategy configuration with a staged approach to ensure successful deployment for pilot to production devices. This is a common use case that you will likely want to implement in your own environment. For descriptions of each section, please see our [Deployment Plan Details](#deployment-plan-details) section below.
### Navigation
1. Click **Strategies** from the side bar navigation.
2. Click **New Strategy**.
### Overview
1. Enter a **Name** and an optional **Description**.
2. Toggle **ON** Strategy Enabled.
### What to patch
1. Toggle **ON** Include All Products or choose individual products.
2. Click **OK**.
3. Click **Next**.
### When to patch
1. Select **Browse** next to **Schedule**.
2. Click the **Schedule** folder and select **2nd Tuesday of Month (00hrs)** from the table.
3. Click **OK**.
4. Click **Next**.
### How to patch
The How to Patch section allows you to select Deployment Rings and add Transitions to customize deployment actions.
1. Click **Next** then select **+ Add Deployment Ring**.
2. Click **Browse** and select the built-in **1% of All Devices (Built-in Pilot)** business unit.
* 1% of All Devices (Built-in Pilot) selects devices at random. If you want a more specific pilot group that represents all aspects of your environment (OS, device type, etc.), please see our [Create Business Unit](/patch/patching-fundamentals/business-units.md#create-a-business-unit) page.
3. Click **+ Add Transition > Delay Transition** and enter 3 days.
* This will allow your admin time to test and verify these devices before deploying to production devices.
4. Click **+ Add Transition > Approval Transition**.
1. Click **Browse** to select the Roles you wish to notify for approval.
2. Set the **Minimum Approvals Needed** to 1 and **Reminder Interval** to 2 hours.
5. Add a pre-production Deployment Ring that has a larger subset of devices than your Pilot Business Unit.
6. Select **+ Add Transition > Success gate**.
1. **Minimum Success Threshold** set to 80% and **Maximum Failure Threshold** to 5%.
* This will ensure that at least 80% of devices must succeed AND no more than 5% can fail deployment.
2. **Failure Action**
* Set to **Roll back, remove from next ring, and continue**.
* This failure action will roll back any patches that may have been installed on successful devices, then the patch will be removed from the deployment, and then the deployment will continue from here.
3. **Send Failure Notification**
* Toggle ON, this will expose additional notification settings.
4. **Roles to Notify**
* Set to desired Roles.
5. **Communication Provider**
* Set to desired provider.
6. **Notification Message**
* Write a descriptive message. e.g. Patch failed to install on greater than 5% of targets. Failing patch was {PatchName}.
7. Click **+ Add Deployment Ring** and select **All devices**.
You have now created a new Strategy that:
* Deploys to a **pilot** business unit for initial testing.
* Deploys to a **pre-production** business unit with a success gate to a larger subset of devices for further validation.
* Deploys to a **production** business unit to deploy to all remaining devices.
If you would like to run your Strategy immediately instead of waiting for the selected scheduled time, you can select the ellipses **(...)** next to your Strategy name in the table and the select **Run Strategy**.
## Deployment plan details
Below is some additional information regarding the Transition settings in the **How to Patch** section of the Strategy walkthrough.
### Add deployment ring
Adding a **Deployment Ring** will allow you to choose which Business Units you'd like the **Strategy** to target for deployment.
{% hint style="info" %}
For more information regarding creating Business Units to add to your Deployment Rings, please see our [Business Units](/patch/patching-fundamentals/business-units.md) page.
{% endhint %}
### Add a transition
Transitions give you the ability to create objects that dictate the behavior of how a patch should be deployed.
#### Approval
You can add an **Approval Transition** that will require a patch to get an approval prior to deployment. With an Approval Transition, you can specify:
* Which Role will be the approval body
* Whether or not you need unanimous approvals or a minimum number of approvals needed
* When to send reminders to approvers after an approval request has been sent
{% hint style="info" %}
Approval request notifications will list all patches included in the approval request for your strategy.
{% endhint %}
#### Delay
**Delay Transition** allows you to delay the deployment of a patch by a specified time after it is received.
* Enter Delay Duration in Days, Hours, Minutes.
#### Success gates
You can create **Success Gate Transitions** to test on a smaller Business Unit before deploying out to a broader scope of devices. After creating your **Strategy** with a **Success Gate**, a [Deployment wave](/patch/advanced-settings/deployment-waves.md) will be automatically generated.
With a **Success Gate** you can define things like:
* A **Minimum Success Threshold** sets how many deployments must succeed by percentage of devices before continuing. For example, if you have 2 devices and you set Minimum Success Threshold to 50%, at least 1 device must be successful before continuing the **Patching Proccess** pipeline.
* Similar to **Minimum Success Threshold**, you can set a **Maximum Failure Threshold** that will fail a **Patching Process** if the percentage of unsuccessful deployments is exceeded. In the same scenario of 2 devices, if you set the maximum to 50% and 1 device failed, it will trigger the **Failure Action**.
* If a particular patch deployment fails, you can specify whether or not to send a **Failure Notification** and if you want it to:
* Abort
* Continue
* Remove from next wave and continue
* Roll back, remove from next wave, and continue
## Patch filters
Patch filters allow you to set constraints on which patches will be applied to your strategy when they meet the desired conditions set by your admin. Each patch filter allows you to set an operating condition and enter the value by which to filter. For a full list of patch filters, please see our [Patch Filters](/patch/advanced-settings/patch-filters-categorized-q1.md) page.
You can include/exclude patches or add multiple patch filters by selecting Operators (AND, OR, NOT).
* **AND**
* If AND is the first selected operator it will need to meet both the conditions of the products include/exclude and the additional patch filter.
* For example, if 7-Zip and Adobe Acrobat are the only products selected AND `General.IsMajorFeature == true`, the patch will need to meet both conditions before being added to the strategy. If a patch is for 7-Zip, but it is not a major feature, it will not be added to the strategy.
* Additional AND operators for additional patch filters follow this same pattern.
* **OR**
* When using the OR operator first, it will act as an AND since we still require a product selection. If you use additional OR operators, the patch will need to meet at least one condition.
* For example, if you have the condition `General.IsMajorFeature == true`and then an OR operator for `Risk.KnownExploitExists == true` only one of these conditions needs to be true for it to be included in the targeted patch list.
* **NOT**
* When NOT is selected as the initial operator, you may only select a single patch filter and cannot add additional operators or filters. This operator will exclude patches based on a selected condition.
* For example, if you have NOT `General.IsMinorFeature == true`, this will select only the patches that are not minor features (i.e. major features, bug fixes, updates, etc.).
Below is an example of how to add a patch filter.
1. Toggle **ON** **Include All Products** or select **Browse** to select desired individual products.
2. Select the ellipses next to **Patch Filter** and select **Add Operator > OR**.
3. Select the ellipses again and select **Add Operating Condition**.
4. Select `Risk.KnownExploitExists` from the **Data Column** dropdown.
5. Use the default for **Operating Condition** (Equals).
6. Set the **Value** to **Medium**
7. Click **OK**.
8. Add another `Risk.KnownExploitExists` and set the value to **High**.
9. Click **Preview Targeted Patches**.
If a product doesn't have any major feature patches, they will not be displayed.
If a product has major features, it will only display major feature patches that have are either a bug fix, or a have a known exploit that exists. 
* Which roles and by which communication provider to send notifications.
* Add a custom **Notification Message**.
* If you hover over the Notification Message tooltip, you can see the available dynamic variables. You can add these variables to your message and it will populate the appropriate data. Dynamic variables include:
* {FirstName} - First name of the administrator that will be notified.
* {LastName} - Last name of the administrator that will be notified.
* {PatchStrategyName} - Name of the patching strategy that has failed.
* {PatchName} - Name of patch(es) that has failed.
* {ProductName} - Name of patch(es) that has failed.
* {Publisher} - Name of the patch publisher.
* {Version} - Version of the patch.
* {TargetCount} - Count of targeted devices.
* {FailureCount} - Count of failed targeted devices.
* {CompliantCount} - Count of targeted devices that are compliant.
* {NonCompliantCount} - Count of targeted devices that are non-compliant.
* {FailureP} - Percentage of target devices that have failed.
* {CompliantP} - Percentage of target devices that are compliant.
**Notification Message/ Dynamic Variable example**
Hello {FirstName} {LastName}, Your patch deployment strategy "{PatchStrategyName}" has completed and had failures.
Patch Details: Patch: {PatchName} Product: {ProductName} Publisher: {Publisher} Version: {Version}
Deployment Results:
Total Devices: {TargetCount} Compliant: {CompliantCount} ({CompliantP}%) Non-Compliant: {NonCompliantCount} Failed: {FailureCount} ({FailureP}%)
Please review the {FailureCount} failed installation(s) in the OneSite console.
Best regards, OneSite Patch Management System
## Monitor patch activity
To monitor patch activity, there are a variety of dashboards you can explore that provide details, such as the date a patch was deployed or whether a patch is pending an approval. Learn more about [Dashboards](https://docs.adaptiva.com/platform-guide/platform-features/dashboards).
However, you may prefer an email summary that you can include in roll-up reports to management or the rest of your team.
### Pre-notifications
If you want to see a list of patches before they are deployed, Approval Requests send out an email notice that there are patches waiting for approval. The link in the email takes you to a dashboard showing all pending approval requests, so you will get an email if you are in the appropriate Approval Chain.
You could also use role-based access control to notify your team, but limit who on that notification list can approve the request. For instance, if you are a Super Admin in the approval chain, but you want a coworker to only have read permissions, then you could set that person's access to Reviewer.
* Learn more about [Approval Requests](https://docs.adaptiva.com/patch/patching-fundamentals/approval-requests)
* Learn more about [Role-based Access Control](https://docs.adaptiva.com/patch/security-and-access-control/rbac)
### Post-notifications
If you want a list of patches that have been deployed in a given week, subscribe to a dashboard that gives you the data you want to see and set it to send out a weekly summary email. For a notification email, **Patch Status - Summary** might be a good candidate.
Note that a patch might not have made it through all the deployment rings before the end of a given week, in which case, the status might show as pending.
Learn more about [Dashboard Subscriptions](https://docs.adaptiva.com/platform-guide/platform-features/dashboards/subscriptions)
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.adaptiva.com/patch/get-started/strategies-v2.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.