---
title: "Blueprints"
slug: "blueprints"
updated: 2026-10-05T12:19:58Z
published: 2026-10-05T12:19:58Z
canonical: "support.controlup.com/blueprints"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.controlup.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Blueprints

Blueprints makes it easier for admins and MSPs to standardize and replicate configurations across tenants without having to configure everything manually. With Blueprints, you can:

- Create reusable configuration templates
- Copy supported entities and settings between tenants
- Override existing configurations or add new ones
- Review changes with versioning and diff preview

This helps you save time, reduce configuration errors, and keep environments consistent at scale.

Blueprints let you build a configuration once from a source tenant and deploy it to as many target tenants as you need, whenever you need to. Before anything is applied, you'll see exactly what will change. Once you run it, you can follow progress tenant by tenant, get notified when it finishes, and look back at every run.

### Use cases for blueprints

Here are a few ways you can put Blueprints to work.

- **Standard tenant onboarding.** Deploy the same baseline configuration to every new tenant, so each one starts out set up the way you want.
- **MSP standardization.** Keep monitoring and automation policies uniform across all the tenants you manage.
- **Controlled change rollout.** Preview the impact of a configuration update before you roll it out, so there are no surprises.
- **Drift correction.** When a tenant has wandered away from your standard, use the diff preview to see exactly where, then run the Blueprint with **Override Existing** to bring it back in line.

### What a blueprint includes

A Blueprint is a reusable configuration template. Each one contains:

- **Name and description**: Your team knows what it's for at a glance.
- **Source tenant**: The tenant the configuration is copied from.
- **Configuration types** you want to include. You can choose any combination of:
  - **Alert rules**
  - **Workflows**
  - **Scripts**
  - **Event logs**
  - **Dashboards**
- **Deployment mode**: Controls how the Blueprint treats configurations that already exist in a target tenant.

Every run is recorded in the Blueprint's execution history, so you always have a clear audit trail of what was deployed, where, and by whom.

### Choose a deployment mode

Pick the mode that matches what you're trying to do. You'll choose it when you create the Blueprint.

| Mode | What happens in the target tenant | Use it when |
| --- | --- | --- |
| **Override Existing** | Existing configurations are replaced by the blueprint's definitions. | You want every tenant to match your standard. |
| **Add to Existing** | Existing configurations stay as they are. Configurations from the blueprint are added alongside them. | You want to roll out something new without touching what a tenant already has. |

> [!NOTE]
> **Important:** **Override Existing** replaces configurations in the target tenant. You'll see what will be replaced in the diff preview before you confirm.

### Create a blueprint

**Before you begin**

- You must have the **Manage blueprints** permission which is available to the Tenant Manager role to create Blueprints.
- Make sure the source tenant has the configurations you want to include.

**To create a Blueprint:**

1. In the Tenant Manager page, select **Blueprints** in the left main menu and click the **Add new bluprint** button.
2. Enter a **Name** and, optionally, a **Description**.
3. Under **Source tenant**, select the tenant to copy your configuration from. Click to continue.
4. Under **Choose what to copy,** select from:
  - Scripts
  - Alert rules
  - Workflows - select whether to include any tags that have been created in Workflows
  - Dashboards - select whether to include any tags that have been created in Dashboards
  - Event logs
  - Custom roles - select whether to include any tags that have been created in your custom roles

or any combination of the above.
5. Under **Deployment mode**, select **Override Existing** or **Add to Existing**.
6. Click **Continue to summary** to review your configuration. If it’s what you want, click **Add blueprint**.

Your Blueprint now appears in the Blueprints list, ready to run.

### Run a blueprint

You can run a Blueprint whenever you need to, on one or more target tenants.

1. In the Tenant Manager page, select **Blueprints** in the left main menu and find a blueprint and click **Run**.
2. In the Run side panel that opens, click the dropdown to **Select** **target tenant tenant/s**.
3. Review the **Impact preview**. You can click to see the full diff details. See [Review the impact preview](/v1/docs/blueprints#review-the-diff-preview) for how to read the diffs between the source tenant and the target tenants.
4. Acknowledge the impact by clicking **I understand the impact of this operation**, then click **Run**.

The run then goes through three phases: validation, deployment, and verification. For details, see [Monitor a run](/docs/blueprints#monitor-a-run).

### Review the impact preview

Before every run, Blueprints show you a preview of what the deployment will do.

#### What the preview shows

- **Total objects affected** across the deployment.
- **A breakdown by configuration type**, so you can see how many alert rules, workflows, scripts, event logs, and dashboards are involved.
- **Conflicts that need your attention.**
- **Overwrite risks**, meaning existing configurations that would be replaced.

#### How items are categorized

Each item in the preview falls into one of four categories:

| Category | What it means |
| --- | --- |
| **New** | The item is in the Blueprint but not in the target tenant. It will be added. |
| **Modified** | The item exists in both places but is different. |
| **Unchanged** | The item is identical in both places. Nothing will change. |
| **Conflict** | The item will cause a collision in the target tenant. Review these before you continue. |

> [!NOTE]
> **Tip:** Start with **Conflict** items, then check **Modified**. In **Override Existing** mode, modified items are the ones that will be replaced in the target tenant.

#### Acknowledge and run

Once you've reviewed the preview, acknowledge the impact and confirm. If something doesn't look right, cancel and nothing is applied.

### What happens during a run

Once you confirm, each run moves through three phases:

1. **Validation.** Blueprints check that the deployment can go ahead before anything changes in your target tenant. [
2. **Deployment.** Blueprints apply the configurations to the target tenant, following the deployment mode you chose.
3. **Verification.** Blueprints confirm that the deployed configurations match what the Blueprint defines.

If you run a Blueprint on several tenants, each tenant has its own status, so you can see exactly where things stand for every tenant.

### Monitor a run

As soon as a run starts, you can track it live. You don't need to refresh or wait until the end to find out how it's going.

You'll see:

- **Real-time progress** for the run.
- **Status for each target tenant**, so a problem in one tenant doesn't get lost in the overall result.
- **Success or failure indicators** for each tenant.

#### Run statuses

| Status | What it means |
| --- | --- |
| **Pending** | The run is queued and hasn't started yet. |
| **Running** | The run is in progress. |
| **Completed** | The Blueprint was deployed successfully. |
| **Partially Completed** | Part of the deployment succeeded and part didn't. |
| **Failed** | The deployment didn't complete. |

#### If a run doesn't fully complete

If a run shows **Partially Completed** or **Failed**:

1. Open the run and check which tenants, and which items, didn't succeed.
2. Fix the issue, then rerun the blueprint on the affected tenants.

### Manage blueprints

Each saved blueprint has an action menu with these options:

- **Edit** a Blueprint to change its name, description, source tenant, configuration types, or deployment mode.
- **Duplicate** a blueprint to start from an existing one. This is handy when you need a variation, such as the same configuration with a different deployment mode.
- **Delete** a blueprint when you no longer need it.

### View job history

The execution history displays every time a blueprint has been run, so you can confirm what was deployed, where, and by whom. It's your audit trail for every deployment.

1. In the Tenant Manager page, select **Blueprints** in the left main menu and click the **Jobs** tab.
2. Select the Blueprint you're interested in and the details of all the blueprint’s runs displays with the date and time it ran with the latest first.

For each run, you can see:

| Detail | What it tells you |
| --- | --- |
| **Source tenant** | Which tenant the configurations were copied from |
| **Target tenants** | Which tenants were copied to |
| **Configuration types included** | Which types were included: alert rules, workflows, scripts, custom roles, event logs, dashboards |
| **Deployment mode** | **Override Existing** or **Add to Existing** |
| **Result** | The final status, using the statuses in [Run statuses](/docs/blueprints#run-statuses). |
| **Executed by** | The user who ran the blueprint |