> For the complete documentation index, see [llms.txt](https://docs.adaptiva.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adaptiva.com/patch/patching-fundamentals/business-units/business-units-best-practices.md).

# Business Units best practices

Best practices for Business Units

When creating or moving Business Units, use these best practices to prevent devices from inadvertently inheriting unwanted settings.

Devices assigned to multiple Business Units will use the settings from the **highest-priority Business Unit** - which is always the **lowest** Business Unit that the device is a member of, as listed in the configuration panel.

![Business Unit priority for device settings](https://2503798551-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7VJNM00p5XQ4pMWqCu8y%2Fuploads%2Fgit-blob-73e64322d26895b4c91e8488b1085216c1b7dd0d%2Fdevice-setting-priority.png?alt=media)

Because of this, creating or moving a Business Unit can cause member devices to inherit different settings than you might expect, potentially triggering immediate patch/reboot cycles.

These best practices will help prevent situations like this.

## Create a restrictive Schedule and Maintenance Window

Create a restrictive schedule and maintenance window that will not be triggered in the near future. These are used for the next best practice, [Give the All Clients Business Unit extremely restrictive settings](#give-the-all-clients-business-unit-extremely-restrictive-settings).

For the purposes of this document we will call these objects **Safety Window**, but you can choose any name.

### 1. Create a **Safety Window** Schedule

* In OneSite Patch, under **Platform Features**, select **Schedules**.
* Click **+ New**.
* Enter **Safety Window** for the schedule name, and optionally add a description.
* In the **Schedule Repeat** field, select **Not Recurring**.
* In the **Start Time** field, click the calendar icon and select a date in the far future, such as Dec 1st, 2075.
* Click **Save and Deploy** to save the new schedule.

### 2. Create a **Safety Window** Maintenance Window

* In OneSite Patch, select **Advanced Settings > Maintenance Windows**
* Click **+ New**.
* Enable the **Apply to All Urgencies** toggle.
* Click **+ Create Maintenance Window**.
* Next to **Start Time Schedule**, click **Browse** (this opens the **Select Schedule** dialog).
* Find and select the **Safety Window** Schedule that you created in the previous step.
* Click **OK** to return to the **Create Maintenance Window** dialog.
* Set the **Duration** field to 2 minutes.
* Click **Create Maintenance Window**.
* Under **Start Time Schedule**, select **Safety Window**.
* Enter **Safety Window** as the Maintenance Window name and optionally add a description.
* Click **Save and Deploy**.

This will create a new Maintenance Window called **Safety Window** that will not be reached in the next 50 years.

## Give the All Clients Business Unit extremely restrictive settings

When you click **+ New** to create a new Business Unit, it is created at the bottom of the list, giving it the ***highest*** priority. It also inherits settings from the root **All Clients Business Unit** by default.

The **All Clients Business Unit** does not define any Maintenance Windows by default, and has the User Interaction Settings set to **Reboot Only - 24 Hour Warning (Anytime)**, which does not respect Maintenance Windows.

This means that if you create a new Business Unit and add devices to it without changing any other settings, the device will not have any Maintenance Windows defined. If any strategy deploys patches to **any** Business Unit that the devices are members of, those devices will immediately attempt to apply the patches and potentially reboot.

To prevent this, edit the **All Clients Business Unit** and make the following changes:

* Set the **Deployment Window** and **Reboot Window** to the **Safety Window** Maintenance Window that you created in the previous best practice.
* Set the **User Interaction Settings** to **Deployment and Reboot - 24 Hour Warning (In Maintenance)**
* Click **Save**.

This will make it so that any direct children Business Units will not apply any patches or reboots unless the Maintenance Windows and User Interaction Settings are specifically set.

## Create two root Business Units for utility and deployment

To help enforce settings priority, you should create the following root level Business Units at the bottom of the list of Business Units, in the following order:

* `Utility` - a parent for Business Units for any utility functions, such as reporting, filtering, exceptions, and rollbacks. These Business Units are typically not part of a strategy.
* `Deployment` - a parent for any Business Units related to deploying patches. Each Business Unit in this group should be included in at least one strategy.

Set the maintenance windows and user interaction settings for these new Business Units with settings that are applicable to the majority of your devices, especially for the `Deployment` Business Unit.

With these new base Business Units, you can create children Business Units under each category by clicking the action menu (**...**) and selecting **Add Child Business Unit**.

This way, device settings in `Deployment` will have priority over device settings in `Utility`, which in turn have priority over device settings in any Business Unit listed above it.

Using these two categories to contain most of your Business Units helps to explicitly define the priority and settings of your devices, reducing the risk of unexpected device patching and reboots.

Note that you can only add devices to a child Business Unit if those devices are also present in the parent Business Unit, so make sure to add devices appropriately to these new Business Units.

## Best practices when moving Business Units

When changing the position of a Business Unit in the list, follow these best practices to avoid unintended deployment behavior:

* **Validate settings**
  * Before moving the Business Unit, review the Business Unit’s settings, including Rollout Processes, approval behavior, maintenance windows, notifications, and interaction settings, and understand which settings are being inherited and what the new settings will be after the change.
  * After the change, validate that the Business Unit's settings match your expectations. If the Business Unit had children, ensure that the children Business Units' settings also meet your expectations.
* **Review device scope and membership**
  * Ensure that all devices in the Business Unit are intended to receive the policies and deployments associated with the new hierarchy.
* **Verify inheritance configuration**
  * Check inheritance toggles after the move to confirm that settings are either correctly inherited from the new parent or explicitly overridden where required.
* **Assess impact on deployment rings**
  * Identify whether the Business Unit or any of its ancestors are included in deployment rings that target descendant Business Units.
    * Remove the Business Unit from rings that no longer apply.
    * Confirm that any inherited ring participation is intentional.
* **Test changes before broad rollout**
  * Where possible, validate hierarchy changes using a lab or test Business Unit before applying them to production environments.