---
title: "Create and manage policy versions"
slug: "bc-create-and-manage-policy-versions"
description: "Manage Data Quality Studio rules effectively with versioning. Learn to navigate, activate, and transition versions without disrupting live policies."
updated: 2026-08-05T06:09:39Z
published: 2026-08-05T06:09:39Z
canonical: "docs.staedean.com/bc-create-and-manage-policy-versions"
---

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

# Create and manage policy versions

Rules in Data Quality Studio are always configured on a **Policy version**, not directly on the policy header. Every policy starts with Version 1 in **Draft** state. You configure rules on the version, and then activate it when ready. Once active, rules run in real time for all users.

The versioning system gives you a safe way to update rules on a live system: configure changes in a new **Draft** version while the current **Active** version continues protecting data. When the new version is ready, activate the new version. The previous version becomes Inactive immediately.

**Purpose**

This section explains how version states work, how to navigate between versions, and how to safely manage version transitions. Understand the version lifecycle so that you can make configuration changes without disrupting a live policy, and activate versions at the right time.

**Navigation**

From the **Data Policies** list, click the **Policy Table ID** (the underlined number, e.g. **18**) to open the **Data Policy** form. All version management happens on this form.

### **Understanding Version States**

| **State** | **What it means** | **Who it affects** |
| --- | --- | --- |
| **Draft** | The version is editable. Rules can be added, changed, or deleted. Rules in this version do **not** run |  |
| **Active** | The version is live. All configured rules triggered, whenever a user creates or edits a record in the governed table. Only **one** version per policy can be **Active** at a time. | All users |
| **Inactive** | A previous version that was superseded when a newer version was activated. Read-only. Rules do not run. Cannot be re-activated directly. | No impact |

> [!NOTE]
> Note
> 
> A policy without an active version does not enforce Anywhere Mobility Solutions rules, even if a draft version with configured rules exists. Rules are applied only when their corresponding version is set to **Active**.

### **Understanding the Data Policy Form**

The **Data Policy** form is the main configuration page for a single version of a policy.

**General section (header):**

| **Field** | **Description** |
| --- | --- |
| **Policy Table ID** | The table this policy governs. Read-only after the policy is created. |
| **Policy Table Caption** | Display name of the table. Auto-populated. |
| **Version No.** | The version number currently shown on the form. Use the navigation arrows (← →) at the sides of the form to move to another version. |
| **Active** | Turn on to activate the version. This deactivates Anywhere Mobility Solutions previously active version |

**Sub-grids (lower section):**

| **Sub-grid** | **What it contains** |
| --- | --- |
| **Field Validation** | The fields whose values are checked by validation rules. Each row = one field. Click a field row and then **Validation Rules** to define the rules for that field. |
| **Duplicate Check Rules** | Duplicate check definitions that are linked to this version. Each row = one duplicate check linked with an Outcome and a message. |

**Summary factbox (right panel):**

| **Field** | **Description** |
| --- | --- |
| **No. of Versions** | Total versions across all states for this policy. |
| **Field Validations** | Count of fields in the **Field Validation** sub-grid for this version. |
| **Duplicate Checks** | Count of duplicate check rules in the **Duplicate Check Rules** sub-grid for this version. |
| **Status Summary** | A system-generated summary. Examples: "Active", "Missing Duplicate Check Rules", "Draft – no rules configured". |

**Duplicate Constraints factbox (right panel, lower):**

When a row is selected in the **Duplicate Check Rules** sub-grid, this factbox shows the fields used for matching by the selected duplicate check definition:

| **Column** | **Description** |
| --- | --- |
| **Field No.** | The field used in the duplicate comparison. |
| **Field Caption** | The field's display name. |
| **Weightage** | Importance of the field in fuzzy matching |

**Navigate between versions**

Each time you open the **Data Policy** form from the **Data Policies** list, it opens on the most recently viewed version. To see other versions:

- Use the **← →** navigation arrows at the left and right edges of the form header.
- The **Version No.** field updates as you navigate.
- The **No. of Versions** in the **Summary** factbox tells you how many versions exist in total.

### **Steps**

**Create a new version**

You can only create new versions from within the **Data Policy** form.

1. Open the **Data Policy** form for the relevant policy.
2. In the action bar, click **+ New**.
3. D365 BC creates the next version number in **Draft** state.
4. The form displays the new (empty) version.
5. Configure validation rules and duplicate check rules on the new version (see [Configure Validation Rules](https://portal.document360.io/manufacturing/docs/configure-validation-rules) and [Configure Duplicate Checks](https://portal.document360.io/manufacturing/docs/configure-duplicate-checks)).

> [!NOTE]
> **Note** New versions start completely empty. Rules are not copied from previous versions. You must configure all required rules on the new version before activating it.
6. When a version is ready, confirm the correct version using **Version No.** in the **General** section.
7. Click the **Active** toggle to turn it on.
8. D365 BC immediately:
  - Sets this version to **Active**.
  - Sets the previously **Active** version (if Anywhere Mobility Solutions) to **Inactive**.
9. Rules from this version now fire for all users creating or editing records in the governed table.

> [!NOTE]
> **Warning** Activation takes effect immediately. Inform affected teams before activating a new version on a production company. Review the configuration carefully in a test company first, and activate the version only when you are ready for the rules to start running.

#### **Deactivate a version (suspend all rules temporarily)**

If you need to temporarily stop all Data Quality Studio rules for a table without deleting anything:

1. Open the **Data Policy** form showing the **Active** version.
2. Turn off the **Active** toggle. The version changes from **Active** to **Inactive**. No version remains active. All rules stop running.

> [!NOTE]
> **Warning** This suspends all Data Quality Studio protection for the table. Users can save records without Anywhere Mobility Solutions validation checks or duplicate detection. Communicate this before doing it on a live system.

### **Examples**

#### **Example 1 - First activation (Version 1 goes live)**

A Customer policy has been configured with validation rules and a duplicate check on Version 1. The setup has been reviewed and is ready for activation.

1. Open the **Data Policies** list, click **18**. Data Policy form opens.
2. Confirm Version No. is **1** and Active is **off**. Summary factbox: Field Validations = 3, Duplicate Checks = 1. Status Summary: *"Draft - rules configured, not active."*
3. Turn on the Active toggle. Now Version 1 is now **Active**. Status Summary updates to **"Active"**.

From this moment, every time a user saves a Customer record, the three validation rules and the duplicate check run automatically.

#### **Example 2 - Update rules without disruption**

Version 1 of the Customer policy is Active and currently in use by the team. The data manager needs to add a new rule that ensures the Credit Limit is greater than 0. Since Version 1 cannot be modified while it is Active, a new version is created.

**Steps:**

1. Open the **Data Policy** form for Customer. Version No. = 1 and **Active** is turned on.
2. Click **+ New** in the action bar.
3. Version 2 is created in **Draft** state. The form switches to Version 2.
4. Add the new **Credit Limit** validation rule to Version 2 (see [Configure Validation Rules](https://portal.document360.io/manufacturing/docs/configure-validation-rules)).
5. Recreate the three existing rules from Version 1 in Version 2, as they are not copied automatically.
6. Review Version 2 carefully in a test company and activate it only when you are ready for the rules to be enforced.
7. When ready: open Version 2 on the **Data Policy** form and turn on the **Active** toggle.
8. Result:
  - Version 1 → **Inactive** (no longer enforced)
  - Version 2 → **Active** (now enforced, including the new Credit Limit rule)

End users experience no interruption, as Version 1 remains active until Version 2 is activated.

**Version history after this:**

| **Version** | **State** | **Rules** |
| --- | --- | --- |
| 1 | Inactive | 3 validation rules, 1 duplicate check |
| 2 | Active | 4 validation rules, 1 duplicate check |

#### **Example 3 - Reviewing the version history**

A functional consultant wants to see the state of a policy over time.

1. Open the **Data Policy** form for **Contact** **(5050)**. Summary factbox shows **No. of Versions = 3**.
2. Use the **←** and **→** navigation arrows to move through versions 1, 2, and 3.
  - Version 1: Inactive. 2 validation rules.
  - Version 2: Inactive. 4 validation rules.
  - Version 3: Active. 5 validation rules, 1 duplicate check.

The consultant can see exactly what was added in each version and when it became **Active** (visible via **Last Date Modified** on the form header if shown, or from the audit trail in D365 BC change log if enabled).

> [!NOTE]
> **Note** You cannot modify rules in **Active** or **Inactive** versions. Always create a new **Draft** version for changes. It ensures there is always a clean, auditable record of what each version contained.