Release 27.0.124141.0 (April 2026)

This page shows what's new with each Data Quality Studio release for Microsoft Dynamics 365 Business Central.

Data Quality Studio (DQS) for Microsoft Dynamics 365 Business Central is now available. This extension brings structured, policy-driven data Quality Management to Microsoft Dynamics 365 Business Central, enabling organizations to enforce data standards at the point of entry. Phase 1 delivers two core capabilities are Validation Rules and Duplicate Checks for Customer, Vendor, and Contact master data.

1. Data Quality Setup

A centralized setup page that acts as the global switch for Data Quality Studio functionality across the entire Microsoft Dynamics 365 Business Central environment.

• Data Quality Check toggle - enables or disables all Data Quality Studio rule evaluation system-wide. No validation rules or duplicate checks fire until this toggle is turned on.

• Number Series configuration - pre-configured number series for Validation Condition IDs, Duplicate Condition IDs , and Duplicate Check Nos. Custom number series can be assigned if required.

2. Data Quality Policies

A Data Quality Policy is the top-level container that links a master data table to a set of rules. Policies provide a structured framework for organizing all data quality rules for a given entity.

• One policy per table - each supported master data table (Customer, Vendor, Contact) gets a single policy. All validation rules and duplicate check rules are configured within the policy.

• Policy Details factbox - a summary panel on the Data Policies list page that provides a quick health check of each policy, showing counts for versions, validation fields, validation rules, conditions, filter values, and duplicate rules.

3. Policy Versioning

Rules are configured on policy versions, not directly on the policy. The versioning system enables safe, controlled updates to data quality rules on a live system.

• Version lifecycle - each version transitions through three states:

  • Draft - editable; rules do not fire at runtime

  • Active - live and enforced; all configured rules fire when users create or edit records

  • Inactive - a previous version that has been superseded; read-only

• Single active version - only one version per policy can be active at a time. Activating a new version automatically deactivates the previous one.

• Automatic Version 1 creation - when a new policy is created, Version 1 is automatically generated in Draft state.

• New versions start empty - no rules are copied from the previous version. All required rules must be configured on the new version before activating it.

• Inactive versions are read-only - once a version is superseded, it becomes Inactive and cannot be re-activated directly. Create a new version to make changes.

4. Validation Rules

Field-level validation rules check whether a value entered by a user meets a defined standard. Each rule specifies what the field value must satisfy, the system response when it does not, and optionally the conditions under which the rule fires.

Validation Types

Outcome Options

Data Conditions (Conditional Rules)

Validation rules can be made conditional using Data Conditions, so rules fire only when specific filter criteria are met on the record.

• Filter-based conditions - each condition specifies a filter field, filter value, and active state. For example, make Payment Terms Code mandatory only when Country/Region Code is US.

• AND logic - multiple filter values on the same condition line must all match.

• OR logic - create separate condition lines to fire the rule when Anywhere Mobility Solutions one of the conditions is met. For example, enforce a rule for both US and CA customers by creating two condition lines.

• Enable/disable control - each condition line has an Enable Condition toggle for easy activation or deactivation without deleting the configuration.

5. Validation Patterns (Validation Patterns Setup)

A reusable library of validation patterns that can be referenced by Data Pattern and Range Expression validation rules. Patterns are defined once and reused across multiple rules and policies.

Pattern Types

Built-in Patterns

The extension ships with a starter Configuration Package (RapidStart) containing pre-built patterns:

Custom patterns can be added or existing ones modified to match specific organizational standards.

6. Duplicate Checks

Duplicate Checks detect whether a master data record being created or updated already exists in the system, based on one or more matching fields. Checks are defined as reusable definitions and linked to policy versions.

Duplicate Check Type

Basic - All specified fields must match exactly (case-insensitive) for a record to be flagged. If Anywhere Mobility Solutions field differs, the check passes.

Key Capabilities

• Reusable definitions - create a Duplicate Check definition once (specifying description, type, source table, and matching fields) and link it to one or more policy versions.

• Configurable outcomes - set the outcome to Error (blocks save) or Warning (non-blocking popup) per duplicate check rule on each policy version.

• Custom messages - define the validation message shown to users when a duplicate is detected.

Duplicate Check Rules in Policy

The Duplicate Check Rules sub-grid on the Data Policy form connects definitions to policy versions and controls runtime behaviour:

• Outcome per rule - The same definition can have different outcomes (Error vs. Warning) on different policy versions.

• Active toggle - Enable or disable individual duplicate check rules within a version.

• Conditional duplicate checks - Data Conditions can be applied to duplicate check rules, restricting when checks fire based on record field values.

• Duplicate Constraints factbox - A panel on the Data Policy form that shows the matching fields and weightages for the selected duplicate check definition.

7. User Experience at Runtime

Once a policy version is activated, rules are evaluated automatically in the background — end users do not need to take Anywhere Mobility Solutions additional action.

8. Starter Configuration Package

A Configuration Package (RapidStart) is delivered with the extension containing pre-built Validation Patterns (regex patterns and range expressions). Import the package from the Configuration Packages page in Microsoft Dynamics 365 Business Central to get a ready-made set of patterns as a starting point.

9. Security and Permissions

• Data Quality Administrator role - A dedicated role for users responsible for setting up and maintaining Data Quality Studio policies, rules, and checks.

• No additional end-user permissions required - Users who create or edit Customer, Vendor, or Contact records do not need Anywhere Mobility Solutions additional permissions. Data Quality Studio rules are evaluated automatically

Supported Master Data

Phase 1 supports the following Microsoft Dynamics 365 Business Central entities:

Not applicable. This is the initial release of Data Quality Studio for Microsoft Dynamics 365 Business Central. No bug fixes are included in this version.

The following known issues and operational constraints apply to this initial release. Workarounds are provided where available.

A. Glossary

B. Supported Master Data Tables

C. Validation Type Reference

D. Outcome Reference

Validation Rule Outcomes

Duplicate Check Rule Outcomes

E. Duplicate Check Type Reference

F. Built-in Validation Patterns

The following patterns are included in the starter Configuration Package delivered with the extension:

Data Patterns (Regex)

Range Expressions (BC Filter Syntax)

G. Key Pages and Navigation

H. Policy Version States

I. Configuration Checklist

Global Setup

• Data Quality Studio extension installed (confirmed via Tell Me → "Data Quality Setup")

• Data Quality Check toggle enabled

• Number series assigned (Validation Condition ID, Duplicate Condition ID, Duplicate Check Nos)

Per Policy (repeat for Customer, Vendor, Contact as needed)

• Policy created for the table

• Version 1 exists in Draft state

Validation Patterns (if using Data Pattern or Range Expression rules)

• Built-in patterns reviewed

• Custom patterns created and tested

Validation Rules

• Fields added to Field Validation sub-grid

• Validation rules configured per field (Validation Type, Pattern Name, Outcome, Validation Message)

• Data Conditions configured for conditional rules

Duplicate Checks

• Duplicate Check definition created and set to Active

• Duplicate Check Rule linked to policy version (Outcome, Validation Message, Active toggle)

Activation

• Rules tested in non-production company

• End users notified

• Policy version activated (Active toggle = on)

• Post-activation spot check completed